Gated multi-encoder machine learning model for distinguishing attacks from normal transactions

Abstract

Machine learning techniques may be applied to distinguish attacks, including enumeration attacks and account test attacks, from normal transaction activities. The integrated machine learning model may include at least two generation units, one of which is trained using normal transaction data and the other is trained using attack transaction data. Each generation unit generates a reconstructed output from a given input in a manner that reflects a potential pattern in a normal transaction or an aggressive transaction. The reconstructed output and raw transaction data may be provided as input to a machine learning classifier, such as a multi-tag (or multi-class) classifier, which determines probability scores for different transaction types (or tags), the different transaction types (or tags) include a first tag indicating a normal transaction, a second tag indicating an attacking transaction, or a third tag indicating an uncertain transaction type. Based on the probability score, the transaction may be classified as a normal type or an attack type.

Description

Technical Field

[0001] The present disclosure relates generally to detecting suspicious activity at a computer system, and particularly to a gated multi-encoder machine learning model for distinguishing attack transactions from normal transactions. Background Art

[0002] Many types of Internet-based activities involve accessing accounts associated with specific users (e.g., individuals). Typically, a user or client wishing to access a service provided by a server proves their authorization by providing the server with credentials for a valid account. In the case of a login, the account credentials may include a username and password. In the case of a financial transaction, the account credentials may include information related to the user's financial account; for example, for a payment made via a purchase card, the data may include the card number, security code (e.g., CVV), expiration date, etc. If valid account credentials are provided to a server by a user or client who is not authorized to use those credentials, fraudulent transactions may result. Fraudulent transactions may have significant negative consequences for the user and / or the service provider. Therefore, there is a need to prevent account credentials from being obtained by unauthorized persons or entities and / or to detect when account credentials have been illegally obtained.

[0003] In an "attack" scenario, an attacker (i.e., a person or entity attempting to conduct fraudulent transactions) attempts to determine valid account credentials. Examples of attacks include enumeration attacks and account testing attacks. In an enumeration attack, the attacker may have partial account information and may attempt to guess the remaining account information. For example, an attacker with a credit card account number but no other information can use different guesses about the missing information to attempt small purchases with several different servers. If the transactions are successful, the attacker can then use the guessed information to make larger fraudulent purchases. In an account testing attack, the attacker may have obtained stolen credentials and can test them to see if they are valid. For example, the attacker may attempt to make one or two small purchases to confirm that the illegally obtained purchase card information corresponds to a valid account, or the attacker may attempt to use stolen account credentials to access different servers. If successful, the attacker may be emboldened to continue with larger-scale fraudulent activities (e.g., making larger purchases or impersonating a user). Therefore, it is ideally desirable to detect such attacks early, before the attacker successfully obtains valid credentials. Summary of the Invention

[0004] Existing techniques for detecting enumeration and account testing attacks are based on rules defined empirically. In a simple example, a rule can provide a list of specific accounts or servers that have been compromised. Other rules can be based on known attack patterns: for example, repeated attempts to use the same partial credentials with varying degrees of completeness (e.g., the same account number with different expiration dates or the same username with different passwords), attempts to use the same or similar credentials with different servers, and so on. However, rule-based approaches require attempting enough transactions for the pattern to become apparent, and once a pattern is detected, there may be further delays before new rules are implemented. Furthermore, it is relatively easy for attackers to change the pattern of their attacks to avoid or delay detection by the rules.

[0005] Certain embodiments described herein relate to systems and methods that use machine learning techniques to distinguish attacks (including enumeration attacks and account testing attacks) from normal transaction activity. In some embodiments, a system may include an integrated machine learning model comprising at least two generators, one of which is trained using normal transaction data and the other trained using attack transaction data. Each generator produces a reconstructed output from a given input that reflects underlying patterns in normal or attack transactions. The reconstructed output and the original transaction data can be provided as input to a machine learning classifier, such as a multi-label classifier (also known as a multi-class classifier), which determines probability scores for different transaction types (or labels). For example, a probability score can be determined for a first label indicating a normal transaction, a second label indicating an attack transaction, or a third label indicating an uncertain transaction type. Based on the probability score, a transaction can be classified as either a normal type or an attack type. This classification can be used to inform further processing of the transaction and / or for other purposes, examples of which are described below. In this way, attack transactions can be quickly identified, thereby reducing the likelihood that an attacker will obtain or use valid account credentials.

[0006] Some embodiments relate to a computer-implemented method, the computer-implemented method comprising: obtaining transaction data of a transaction; providing the transaction data as input data to a machine learning model, the machine learning model having been trained to classify transactions using a set of labels, wherein the set of labels comprises a first label indicating a normal transaction type, a second label indicating an attack transaction type, and a third label indicating an uncertain type of transaction, wherein the machine learning model comprises: a plurality of generation units comprising a first generation unit associated with a normal transaction type and a second generation unit associated with an attack transaction type, wherein each of the generation units receives input data and outputs a reconstruction of the input data, wherein the generation units operate independently of one another; a join gate that generates intermediate data by combining corresponding reconstruction outputs from the plurality of generation units with the input data; and a multi-label classifier unit that determines a probability score for each of the labels in the set of labels based on the intermediate data; and classifying the transaction as a normal transaction or an attack transaction based at least in part on the probability score for each of the labels in the set of labels.

[0007] In these and other embodiments, the method may also include: obtaining a training dataset comprising transaction data for a plurality of transactions, wherein at least some of the transaction data in the training dataset is initially unlabeled; and using the training dataset to train a machine learning model, wherein training the machine learning model includes: directing transaction data having a first label to a first generation unit; directing transaction data having a second label to a second generation unit; and randomly directing unlabeled transaction data and transaction data having a third label to one or more of the generation units.

[0008] In these and other embodiments, all, some, or no transaction data in the training data set may be initially labeled.

[0009] In these and other embodiments, training of the machine learning model may include multiple training epochs, and at the end of each training epoch, an updated label may be assigned to the transaction data of at least one of the transactions in the training dataset based on the probability score determined by the multi-label classifier unit.

[0010] In these and other embodiments, classifying the transaction may include: determining which tag in the set of tags has a highest probability score; if a first tag has the highest probability score, classifying the transaction as a normal transaction; if a second tag has the highest probability score, classifying the transaction as an attack transaction; and if a third tag has the highest probability score: determining which tag in the set of tags has a second highest probability score; if the first tag has the second highest probability score, classifying the transaction as a normal transaction; and if the second tag has the second highest probability score, classifying the transaction as an attack transaction.

[0011] In these and other embodiments, the method may further include assigning an uncertainty score to the classification of the transaction as a normal transaction or an attack transaction based on the probability score of the third tag.

[0012] In these and other embodiments, transaction data may be received while the transaction is in progress, and the method may further include determining whether to allow or deny the transaction based at least in part on whether the transaction is classified as a normal transaction or an attack transaction.

[0013] Some embodiments relate to a computer system that may include: a communication interface for communicating with one or more server systems; a memory for storing transaction data of a plurality of previous transactions, the plurality of previous transactions including a plurality of normal transactions and a plurality of attack transactions; and a processor coupled to the memory and configured to implement a machine learning model, the machine learning model including: a plurality of generation units including a first generation unit associated with a normal transaction type and a second generation unit associated with an attack transaction type, wherein each of the generation units receives input data representing a transaction and outputs a reconstruction of the input data, wherein the generation units operate independently of each other; a combining gate that combines the corresponding outputs from the plurality of generation units with the input data; input data to generate intermediate data; and a multi-label classifier unit, which determines a probability score for each label in a set of labels based on the intermediate data, wherein the set of labels includes a first label indicating a normal transaction type, a second label indicating an attack transaction type, and a third label indicating an uncertain type of transaction, wherein the processor is further configured to; train a machine learning model using the stored transaction data; receive new transaction data from one of the one or more server systems via a communication interface; use the trained machine learning model to determine a probability score for each of the labels in the set of labels for the new transaction data; and classify the transaction as a normal transaction or an attack transaction based at least in part on the probability score for each of the labels in the set of labels.

[0014] In these and other embodiments, at least one of the generation units may include a variational autoencoder.

[0015] In these and other embodiments, the multi-label classifier unit may include a feed-forward neural network having one or more layers.

[0016] In these and other embodiments, the transaction data for each transaction may include account credentials provided by the client system to the server system, where the normal transaction type corresponds to authorized use of the account credentials, and where the attack transaction type corresponds to attempted or successful unauthorized use of the account credentials.

[0017] In these and other embodiments, the processor may be further configured such that training the machine learning model includes: defining a training data set using at least a portion of the stored transaction data, wherein the training data set initially includes at least some transactions with a first label, at least some transactions with a second label, at least some transactions with a third label, and at least some unlabeled transactions; directing the transaction data for transactions with the first label to a first generation unit; and directing the transaction data with the second label to a second generation unit.

[0018] In these and other embodiments, the processor may be further configured such that training the machine learning model includes randomly directing each of the transactions with the third label to one or the other of the first generation unit or the second generation unit; and randomly directing each of the unlabeled transactions to one or the other of the first generation unit or the second generation unit.

[0019] In these and other embodiments, the processor may be further configured such that training the machine learning model includes: directing a randomly selected subset of transactions with the third label to both the first generation unit and the second generation unit; and directing a randomly selected subset of unlabeled transactions to both the first generation unit and the second generation unit.

[0020] In these and other embodiments, training of the machine learning model may include multiple training epochs, and the processor may be further configured such that at the end of each training epoch, updated labels are determined for transactions with the third label in the training dataset and for unlabeled transactions, wherein the updated labels for the transactions are determined based on the probability scores determined by the multi-label classifier unit.

[0021] Some embodiments relate to a computer-readable storage medium having program code instructions stored therein, which, when executed by a processor in a computer system, cause the processor to perform a method comprising: obtaining transaction data of a transaction; providing the transaction data as input data to a machine learning model that has been trained to classify transactions using a set of labels, wherein the set of labels includes a first label indicating a normal transaction type, a second label indicating an attack transaction type, and a third label indicating an uncertain type of transaction, wherein the machine learning model includes: a plurality of generation units, including a first generation unit associated with a normal transaction type and a second generation unit associated with an attack transaction type, wherein each of the generation units receives input data and outputs a reconstruction of the input data, wherein the generation units operate independently of each other; a combining gate that generates intermediate data by combining corresponding outputs from the plurality of generation units with the input data; and a multi-label classifier unit that determines a probability score for each of the labels in the set of labels based on the intermediate data; and classifying the transaction as a normal transaction or an attack transaction based at least in part on the probability score for each of the labels in the set of labels.

[0022] In these and other embodiments, the method may further include: obtaining a training dataset comprising transaction data for a plurality of transactions, wherein at least some of the transaction data in the training dataset is initially unlabeled; and training a machine learning model using the training dataset, wherein training the machine learning model comprises a plurality of training epochs, and wherein, during each epoch: transaction data with a first label is directed to a first generation unit; transaction data with a second label is directed to a second generation unit; and unlabeled transaction data and transaction data with a third label are randomly directed to zero or more generation units.

[0023] In these and other embodiments, the method may further include, after each training epoch, applying the machine learning model to the unlabeled transaction data and the transaction data with the third label to determine a probability score for each of the labels in the set of labels; and determining updated labels for the unlabeled transaction data and the transaction data with the third label based on the probability score for each of the labels in the set of labels.

[0024] In these and other embodiments, the transaction data may be received from a server computer, and the method may further include transmitting a report to the server computer indicating whether the transaction is classified as a normal transaction or an attack transaction. In these and other embodiments, the report may further include an uncertainty score based on the probability score of the third tag.

[0025] The following detailed description and attached Figure 1Together, they will provide a better understanding of the nature and advantages of the claimed invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 A simplified block diagram is shown of a system in which some embodiments may operate.

[0027] Figure 2 A simplified block diagram showing a machine learning model according to some embodiments.

[0028] Figure 3 A flowchart showing a process for training a machine learning model according to some embodiments.

[0029] Figure 4 A simplified block diagram showing a machine learning model in inference mode according to some embodiments.

[0030] Figure 5 A flowchart showing a process for operating a machine learning model in inference mode according to some embodiments is shown.

[0031] Figure 6 A flow chart showing a process for determining a classification for a transaction according to some embodiments.

[0032] Figure 7 A simplified block diagram showing a machine learning model according to some embodiments.

[0033] the term

[0034] The following terms may be used herein.

[0035] A "computer system" generally refers to a device or apparatus capable of executing program code (also called "instructions"). A computer system may include a processor and memory, as well as other components, such as a user interface that enables humans to interact with the computer system and / or a communication interface that enables the computer system to exchange information-bearing signals with other computer systems.

[0036] "Processor" may refer to any suitable data computing device or devices. A processor may include one or more microprocessors that work together to perform the desired functionality. A processor may include a CPU that includes at least one high-speed data processor sufficient to execute program components for performing user and / or system generated requests. A CPU may be a microprocessor such as AMD's Athlon, Duron, and / or Opteron; IBM and / or Motorola's PowerPC; IBM and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xenon, and / or XScale; and / or similar processors. A processor may also include one or more coprocessors that operate under the control of the CPU to perform specific tasks; examples include graphics processors, neural processors, etc.

[0037] A "server computer," "server system," or "server" may refer to a computer or a cluster of computers. A server computer may be a powerful computing system, such as a mainframe. A server computer may also include a cluster of smaller computers or a group of servers operating as a unit. In one example, a server computer may include a database server coupled to a network server. In another example, a server computer may include a collection of processors, a communication interface for receiving requests to perform work using the processors, and a control system for assigning work to specific processors. A server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to service requests from one or more client computers.

[0038] A "client computer," "client system," or "client" may refer to a computer or cluster of computers that receives a service from a server computer (or another computing system). A client computer may access this service via a communications network, such as the Internet or any other suitable communications network. A client computer may issue requests to a server computer, including requests to retrieve or update data or to purchase goods or services. As some examples, a client computer may send a request to a server computer to access a user account to retrieve and / or update data in a database maintained by the server computer, or a client computer may send a request to a server computer to charge a purchase of goods or services to a purchasing card or other financial account. A client computer may include one or more computing devices and may use various computing structures, arrangements, and compilations to perform its functions, including requesting and receiving data or services from a server computer.

[0039] A "transaction" may generally refer to an interaction in which a client computer or client system seeks to obtain something (e.g., data, goods, services) from or via a server computer or server system. A transaction may require the client (or user of the client computer) to provide account credentials as evidence that the user is authorized to obtain the sought content and / or to facilitate the completion of the transaction. As some examples, a username and password may be required to authorize access to data; or a card number, expiration date, and other information may be required to authorize the purchase of goods or services.

[0040] "Account credentials" or "credentials" may include any combination of information items that can be used by a server system to determine whether a client system, or a particular user of a client system, is authorized to perform a transaction with the server system. Examples of account credentials include a username, password, email address, account number, additional account information (e.g., expiration date, card verification value (CVV) for a purchasing card), etc. The account credentials may be verified by the server before authorizing a transaction. Depending on the implementation, the server may perform its own verification and / or communicate with one or more other servers to verify the credentials.

[0041] A “machine learning model” may refer to a file, program, software executable, instruction set, etc. that has been “trained” to recognize patterns or make predictions. For example, a classifier is a type of machine learning model that can receive input data and determine the probability that the input data belongs to each of a plurality of categories, where each category is identified by a label. As another example, a generative model can take input data (represented as a sequence or feature vector) and generate outputs that are variations or extensions of the input based on patterns learned during training. A machine learning model can be trained using “training data” (e.g., to identify patterns in the training data) and then applied when using this training for its intended purpose. A machine learning model can be defined by “model parameters,” which can include numerical values ​​that define how the machine learning model performs its function. Training a machine learning model can include an iterative process for determining a set of model parameters that achieve optimal performance for the model. DETAILED DESCRIPTION

[0042] The following description of exemplary embodiments is presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the claimed embodiments to the precise form described, and those skilled in the art will appreciate that many modifications and variations are possible. The embodiments have been chosen and described in order to best explain their principles and practical applications, thereby enabling others skilled in the art to best make and use the various embodiments and make various modifications as are suited to the particular use contemplated.

[0043] System Overview

[0044] Figure 1 A simplified block diagram of a system 100 in which some embodiments may operate is shown. System 100 includes several client systems 102 communicating with various server systems 104 via a network 106, which may be, for example, the Internet, a local area network, a private network, or any other network. In some instances, a particular client system 102 may interact with one of the server systems 104 to perform a transaction, as indicated by dashed arrow 107. The transaction may be of a type that involves verifying that the user of the client system 102 should be allowed to perform the transaction. For example, server system 104 may request account credentials from client system 102. In response, client system 102 may prompt the user to enter appropriate account credentials (or client system 102 may retrieve the user's locally stored account credentials). Client system 102 may transmit the account credentials (preferably in a secure manner) to server system 104, and server system 104 may determine whether the account credentials are valid. If the credentials are valid, the transaction may be allowed; if not, the transaction may be denied (or blocked).

[0045] The various server systems 104 can support many different types of transactions, and the account credentials used can depend on the specific transaction. For example, in a transaction in which a user retrieves data from or adds data to a server system 104, the user (via client system 102) may be required to provide a username and password, and possibly other information (e.g., a one-time code or answer to a security question). In a purchase transaction, the user may be required to provide an account number (e.g., a primary credit card account number), a security code (e.g., a card verification value or CVV), an expiration date, a partial or complete billing address (e.g., a zip code), and / or other information. In some instances, multiple server systems 104 may be involved in a transaction. For example, a client system 102 may be used to order goods or services via a first server 104. In conjunction with a transaction, a user may provide account credentials for a financial account, and the first server 104 may communicate with a second server system 104 to verify the account credentials and charge the financial account. More generally, one server system 104 may communicate with another server system 104 to verify the account credentials received from a client. The specific implementation of the transaction, including verification of account credentials, may be modified as desired without departing from the scope of the present disclosure.

[0046] A user may use client system 102 to conduct transactions with server system 104. As used herein, a "normal" transaction is one in which the user is actually authorized to use the account credentials presented in connection with the transaction, including transactions in which the user initially makes an error when entering the account credentials and corrects the error when prompted to re-enter the credentials. It is expected that most transactions will be of the normal type. A "fraudulent" transaction is one in which a user obtains authorization using account credentials that the user knows they are not authorized to use, such as where the user steals or guesses the credentials. An "attack" transaction is an attempt to conduct a fraudulent transaction. For example, an attacker may attempt to guess valid credentials (an "enumeration attack"), or an attacker may test the validity of illegally obtained credentials by performing transactions with an unsuspecting server system 104 (an "account testing attack").

[0047] To avoid detection, an attacker may attempt to maintain a low profile. For example, an attacker may attempt small purchases or make seemingly innocuous data requests in order to determine whether known or suspected credentials are valid. In addition, an attacker may attempt such transactions with different server systems 104 (e.g., using different guesses for credentials) to make the attack more difficult to detect. If an attacker learns of valid credentials, the attacker may escalate to, for example, larger fraudulent purchases, corruption or destruction of data, or other harmful activities.

[0048] According to some embodiments, a monitoring system 110 connected to the network 106 can be used to detect attack transactions. The monitoring system 110 can communicate with any or all of the server systems 104 to determine whether an attempted or completed transaction is normal or a possible attack. For example, the monitoring system 110 can maintain a machine learning model 120, an embodiment of which is described below. The machine learning model 120 can be trained to receive transaction data 122 of a transaction and assign a label 124 to the transaction data 122. The label 124 can indicate, for example, whether the transaction is likely normal or likely an attack. In some embodiments, a confidence score, such as a probability score or an uncertainty score, can be associated with the label 124.

[0049] The monitoring system 110 can be used for a variety of purposes. In some embodiments, one or more server systems 104 can send transaction data 122 for a transaction to the monitoring system 110 in real-time (while the transaction is ongoing). The monitoring system 110 can transmit a report back to the server system 104, which can include a tag 124 and a confidence score. The server system 104 can use the report to determine whether to approve or deny the transaction. As another example, in some embodiments, the monitoring system 110 can use the tag 124 to determine whether to approve or deny the transaction and can send the approval or denial to the server system 104. In addition to or in lieu of real-time monitoring, the monitoring system 110 can also periodically receive batches of transaction data from one or more server systems 104 and analyze the transaction data using the machine learning model 120 to identify possible attacks, assess the current level of attack activity, and / or detect emerging attack patterns. Regardless of whether the monitoring system 110 is used in real-time mode or batch mode, the monitoring system 110 can notify the server system 104 of the attack, and the server system 104 can take appropriate remedial actions, such as denying transactions, invalidating account credentials used in the attack, contacting users whose credentials may have been compromised, reporting the attack to law enforcement, etc.

[0050] It should be understood that system 100 illustrates one scenario in which detecting attacking transactions can be useful. The techniques used herein can be applied to any scenario in which a server system receives and processes transaction requests from a client system. Monitoring system 110 can interact with any number (one or more) of server systems 104. In various embodiments, monitoring system 110 and the server systems 104 with which monitoring system 110 interacts can be operated by the same entity or by different entities.

[0051] Machine Learning Models for Attack Detection

[0052] To date, the use of machine learning to detect attack transactions has been limited, in part because conventional machine learning classifiers perform best when the training data is balanced between the learned classes (or labels). In the case of transactions between clients and servers, attacks typically constitute only a small fraction of all transactions, and an imbalance between attack and normal transactions in the training data can disrupt the machine learning process. Certain embodiments described herein provide machine learning models that can perform effectively with imbalanced and / or unlabeled training data.

[0053] Figure 2 A simplified block diagram of a machine learning model 200 is shown according to some embodiments. The machine learning model 200 can be used to implement, for example Figure 1The machine learning model 120. The machine learning model 200 may be an integrated model comprising a “normal” generation unit 210, an “attack” generation unit 220, and a multi-label classifier unit 230. Figure 2 , the machine learning model 200 is shown in training mode.

[0054] In training mode, the machine learning model 200 can receive training data 202. The training data 202 can include transaction data from previous transactions, including any combination of accepted and rejected transactions at any number of server systems 104. The transaction data for a given transaction can include any information about the transaction, including any or all of the following: the credentials used; whether the credentials were determined to be valid; information about the client system (e.g., IP address; identifier of the Internet Service Provider (ISP) used by the client system; and / or client platform information, including hardware type, operating system, specific application used to access the server, hardware or software version information); information about the server system (e.g., IP address, owner / operator of the server, server platform information); date and time; whether the transaction was allowed or rejected; and / or other information (e.g., number of errors in entering the credentials during the transaction; specific items downloaded, uploaded, or ordered; monetary value purchased; user address information; recent transactions preceding the current transaction). While the machine learning model 200 can be applied in a variety of contexts, it is preferred to select training data related to a single category of account credentials. For example, an attack aimed at guessing or testing login credentials may have different characteristics than an attack aimed at guessing or testing purchase card account credentials. Therefore, a particular embodiment of the machine learning model 200 can be trained to analyze transactions involving a particular class of account credentials (e.g., login credentials or purchase card credentials, but not both in the same embodiment). Optionally, multiple embodiments of the machine learning model 200 can be provided to support detection of attacks targeting different classes of account credentials.

[0055] For each transaction in the training dataset, input data (e.g., an input feature vector representing some or all of the transaction data) can be defined. The input feature vector can be input to one or both of a normal generation unit 210 and / or an attack generation unit 220. For example, the normal generation unit 210 can be a variational autoencoder (VAE) unit having a variational encoder 212 that produces a latent space embedding 214 and a variational decoder 216 that produces a "normal" reconstruction 218 (e.g., as a feature vector having the same dimensions as the input feature vector). Similarly, the attack generation unit 220 can also be a VAE unit having a variational encoder 222 that produces a latent space embedding 224 and a variational decoder 226 that produces an "attack" reconstruction 228 (e.g., as another feature vector having the same dimensions as the input feature vector). The generation units 210 and 220 can be implemented using conventional or other techniques, and different generation units can have the same, similar, or different structures (e.g., the number of encoding and / or decoding layers, the dimensions of the latent space). Even if the normal generation unit 210 and the attack generation unit 220 have the same structure, the normal generation unit 210 and the attack generation unit 220 can be trained based on systematically different data (as described below); therefore, the normal reconstruction 218 and the attack reconstruction 228 generated from the same input transaction are expected to exhibit systematic differences.

[0056] Combine gate 208 may receive input feature vectors for normal reconstruction 218, attack reconstruction 228, and the transaction, and may generate a concatenated or combined representation of normal reconstruction 218, attack reconstruction 228, and the input feature vectors as intermediate data. For example, combine gate 208 may concatenate the feature vectors of the input data, normal reconstruction 218, and attack reconstruction 228. In this case, if the input feature vector has n dimensions (or components), combine gate 208 generates intermediate data in the form of a feature vector of dimension 3n. As another example, combine gate 208 may calculate a first difference vector representing the difference between the input feature vector and the normal reconstruction vector, and a second difference vector representing the difference between the input feature vector and the attack reconstruction vector, and then concatenate the first and second difference vectors. In this case, if the input feature vector has n dimensions (or components), combine gate 208 generates intermediate data in the form of a feature vector of dimension 2n. This reduction in dimensionality can reduce computational burden while causing negligible information loss.

[0057] The multi-label classifier unit 230 can be implemented, for example, using a feedforward neural network with any number of fully connected layers. Conventional or other techniques can be used to implement a suitable classifier. The multi-label classifier unit 230 can map the output feature vector from the combination gate 208 to a probability score for each label in a defined set of labels 232. In this example, the set of labels 232 includes a "normal" label with a normal probability score 234, an "attack" label with an attack probability score 236, and an "uncertain" label with an uncertain probability score 238. The "uncertain" label can be used to identify a feature vector between a normal type and an attack type. In some embodiments, the probability scores of the labels can be normalized so that their sum is 1. The labels can correspond to different classes, and the terms "multi-label classifier" and "multi-class classifier" are used interchangeably in this article.

[0058] Training a machine learning model involves an automated process of determining or "learning" optimal values ​​for the model's internal parameters, such as the weights of each node, or the coefficients of a parametric function, such as a curve fit function or a transformation function. Standard training methods involve iteratively processing data samples through the model and adjusting the model's parameters, with the goal of minimizing a loss function, which characterizes the difference between the model's output for a given input and the expected result determined from a source other than the model. The loss function can be selected based in part on the specific model, and various techniques can be used to optimize the loss function. An example of a loss function for a machine learning model 200 is described below. Training typically occurs across multiple "epochs," where each epoch corresponds to a pass through the training sample set. Adjustments to the model's parameters (e.g., weights or coefficients) can occur multiple times during an epoch; for example, the training data can be divided into "batches" or "mini-batches," and weight adjustments can occur after each batch or mini-batch. Aspects of machine learning models and training relevant to understanding the present disclosure are described herein; any other aspects may be modified as needed.

[0059] To train the machine learning model 200, the training data 202 may initially include any combination of labeled and unlabeled transaction data. For example, during the preparation of the training data 202, human reviewers or rule-based analysis may be used to label some (or all) transactions as normal, attack, or uncertain. As described below, pre-labeling of the training data 202 is not required, and the machine learning model 200 may learn from the initial unlabeled training data.

[0060] Tag gate 204 and select gate 206 can be used to direct transaction data for a given transaction to one or the other (or both) of normal generation unit 210 or attack generation unit 220. In some embodiments, when transaction data is sent to only one of normal generation unit 210 or attack generation unit 220, a null (or zero) vector is sent to the other of normal generation unit 210 or attack generation unit 220. More specifically, tag gate 204 can read any tags that have been applied to the transaction data. If a normal tag has been applied, tag gate 204 can direct the transaction data to normal generation unit 210 (and direct the null vector to attack generation unit 220). If an attack tag has been applied, tag gate 204 can direct the transaction data to attack generation unit 220 (and direct the null vector to normal generation unit 210). If an uncertain tag has been applied, or if the transaction data is unlabeled, tag gate 204 can direct the transaction data to select gate 206.

[0061] The selection gate 206 can be implemented to randomly (or quasi-randomly) assign transactions to one, both, or neither of the normal generation unit 210 and the attack generation unit 220. As one example, the selection gate 206 can implement a random exit gate that directs a predefined fraction (or subset) of transactions received at the selection gate 206 (which will only be transactions without a label or with an uncertain label) to both the normal generation unit 210 and the attack generation unit 220; the other transactions received at the selection gate 206 are not directed to either generation unit (these transactions are discarded during the current training epoch). As another example, the selection gate 206 can implement a random separation gate that, for each transaction received at the selection gate 206 (which will only be transactions without a label or with an uncertain label), randomly directs transaction data to one or the other of the normal generation unit 210 or the attack generation unit 220, and directs a null vector to the unselected one of the normal generation unit 210 or the attack generation unit 220. An example of the operation of selection gate 206 is described below.

[0062] Figure 3 A flowchart illustrating a process 300 for training a machine learning model 200 according to some embodiments is shown. At block 302, a training dataset is obtained. The training dataset may include transaction data from a large number of transactions. None, some, or all transactions may be labeled with a true value label identifying the transaction as normal or an attack. At block 304, each transaction in the training dataset may be represented as a feature vector that may include a representation of all available information about the transaction or a subset of the available information. Optionally, the training dataset may be divided into multiple batches.

[0063] Per-transaction logic is applied to route transaction data to generation units based, at least in part, on the truth labels assigned to the transactions. If, at block 306, a particular transaction has been labeled as a normal transaction, then, at block 308, the transaction data (feature vector) for that transaction is directed (e.g., by the label gate 204) to the normal generation unit 210, and a null vector is directed to the attack generation unit 220. Conversely, at block 310, if a particular transaction has been labeled as an attack transaction, then, at block 312, the transaction data (feature vector) for that transaction is directed (e.g., by the label gate 204) to the attack generation unit 220, and a null vector is directed to the normal generation unit 210. At block 314, if the particular transaction is unlabeled or has an uncertain label, the selection gate 206 may be operated to randomly direct the transaction data (feature vector) to zero or more generation units. For example, selection gate 206 may implement a random exit gate that directs a predefined fraction x of transactions received at selection gate 206 to both normal generation unit 210 and attack generation unit 220. The predefined fraction x may be defined to reflect a general level of uncertainty, such as an expected fraction of edge cases that can be determined empirically. In this context, "edge cases" may include situations involving incorrect credentials that are not typically attributed to attempted fraud, such as a situation where a user initially makes an error when entering account credentials and corrects the error when prompted to re-enter the credentials. (As a specific example, in an embodiment where 20% of transactions are expected to be edge cases, x may be 0.20.) In this example, when selection gate 206 receives a transaction, selection gate 206 may generate a random number (uniformly distributed between 0 and 1) and compare the random number to the predefined fraction x. If the random number is higher than the predefined fraction x, selection gate 206 may direct the transaction data (feature vector) to both normal generation unit 210 and attack generation unit 220; otherwise, the transaction is not used (discarded) in the current training epoch. In this way, transaction data of a randomly selected subset of unlabeled transactions and transactions with uncertain labels can be directed to both the normal generation unit 210 and the attack generation unit 220 .

[0064] As another example, in some embodiments, selection gate 206 may implement a random separation gate that randomly directs transactions to either normal generation unit 210 or attack generation unit 220. Similar to the random exit example, a predefined fraction x may be defined to reflect the expected ratio of attack transactions to normal transactions, which can be determined empirically. (As a specific example, in an embodiment where 99% of transactions are expected to be normal, x may be 0.01.) When selection gate 206 receives a transaction, it may generate a random number (uniformly distributed between 0 and 1) and compare the random number to the predefined fraction x. However, in this case, if the random number is below the predetermined fraction x, selection gate 206 may direct the transaction data (feature vector) to attack generation unit 220 (and a null vector to normal generation unit 210), and if the random number is above the predetermined fraction x, selection gate 206 may direct the transaction data (feature vector) to normal generation unit 210 (and a null vector to attack generation unit 220).

[0065] At block 316, the normal generation unit 210, the attack generation unit 220, the combination gate 208, and the multi-label classifier unit 230 operate on the received transaction data (feature vectors) as described above to generate outputs. For each transaction, the outputs may include a normal reconstruction 218, an attack reconstruction 228, and probability scores 234, 236, 238 for the labels in the label set 232.

[0066] At block 318, a loss function may be calculated for each batch. For example, where the normal generation unit 210 and the attack generation unit 220 are implemented as variational autoencoders, the feature vector input to either unit produces a reconstructed output, where the subscript index identifies the data sample and the superscript index identifies the specific generation unit (e.g., indicating the normal generation unit 210, indicating the attack generation unit 220). The loss function for a given generation unit and feature vector may be defined as the distance between the input feature vector and the reconstructed output, i.e.:

[0067]

[0068] distance metric It can be, for example, Euclidean distance or other distance metrics.

[0069] For the multi-label classifier unit 230, the loss function of label mapping can be defined as:

[0070]

[0071] where index l identifies the label, is the probability score output by the multi-label classifier unit 230 for label l, and if label l is the true value label, then is equal to 1, otherwise equal to 0. In this example, the loss is calculated only for input data with normal or attack labels; for input feature vectors that are unlabeled or labeled as uncertain, the loss of the multi-label classifier unit 230 is set to 0.

[0072] The total loss function for each batch (calculated at block 316) can be defined as:

[0073]

[0074] where w is a weight factor (a hyperparameter of the model) and is summed over all training examples i in the batch.

[0075] At block 318, after processing the batch, the loss may be back-propagated through the model to adjust the weights in each layer of the variational encoders 212, 222, variational decoders 216, 226, and multi-label classifier unit 230. Conventional or other back-propagation techniques may be used.

[0076] At block 320, after each training epoch, any transactions that do not have a true label or whose true label is uncertain can be updated using predictions from the machine learning model 200 (operating in inference mode, as described below). For example, if the probability score for either the normal label (probability score 234) or the attack label (probability score 238) exceeds a threshold (e.g., 50% or 60% probability), the transaction can be assigned the corresponding label. If neither probability score exceeds the threshold, the transaction can be marked as uncertain. In some embodiments, once a transaction has been assigned a normal label or an attack label, the label for that transaction remains fixed for the duration of the training. Thus, as training progresses, more training data can acquire normal or attack labels.

[0077] Although Figure 3 Only one training epoch is shown, but it should be understood that additional training epochs may be performed as needed. In some embodiments, training may continue until a stopping criterion is met. Suitable techniques for defining stopping criteria are known in the art. Using process 300, machine learning model 200 may learn patterns of attacks, including attacks that may not yet have occurred.

[0078] Process 300 can support supervised, semi-supervised, or unsupervised training. Thus, the training dataset can initially include any combination of labeled and unlabeled transaction data. As described above, as training progresses, labels can be assigned to initially unlabeled transactions. In some embodiments, training can be repeated (continuously or periodically, such as daily, weekly, or monthly) as additional training data becomes available, allowing the machine learning model 200 to learn emerging attack patterns.

[0079] After initial training, the machine learning model 200 can be used in “inference” mode to apply labels to new (or previously unseen) transactions. Figure 4 A simplified block diagram of the machine learning model 200 in inference mode, according to some embodiments, is shown. In inference mode, transaction data 402 of a transaction to be labeled can be represented as a feature vector and input to both the normal generation unit 210 and the attack generation unit 220. (The label gate 204 and the selection gate 206 are not used in inference mode.) The normal generation unit 210 can generate a normal reconstruction 418 from the transaction data 402, while the attack generation unit 220 can generate an attack reconstruction 428. It should be understood that because the normal generation unit 210 and the attack generation unit 220 are trained using different types of transactions, the normal reconstruction 418 and the attack reconstruction 428 for the same input transaction data 402 will typically be different. The combine gate 208 can combine or concatenate the input transaction data 402 with the normal reconstruction 418 and the attack reconstruction 428 (in the same manner as in training mode), and the multi-label classifier unit 230 can use the output of the combine gate 208 as input to map to a probability score for each of the labels in the label set 232. Thus, in inference mode, the machine learning model 200 can generate a normal probability score 434, an attack probability score 438, and an uncertain probability score 436 for the transaction. In some embodiments, the probability scores 434, 436, 438 can be used to classify a transaction as a normal transaction or an attack transaction.

[0080] Figure 5 A flow chart showing a process 500 for operating a machine learning model 200 in inference mode according to some embodiments. When one of the server systems 104 requests a real-time evaluation of an ongoing transaction, it can be performed in, for example, Figure 1 The process 500 is used in the monitoring system 110.

[0081] At block 502, input transaction data 402 may be received (e.g., from server system 104). The input transaction data may be represented as feature vectors corresponding to the feature vectors used in training the machine learning model 200. At block 504, the transaction data (feature vectors) is routed to both the normal generation unit 210 and the attack generation unit 220, which generate a normal reconstruction 418 and an attack reconstruction 428, respectively. At block 506, the join gate 208 may combine or concatenate the input transaction data 402 with the normal reconstruction 418 and the attack reconstruction 428 (in the same manner as in training mode). At block 508, the multi-label classifier unit 230 operates to generate probability scores 434, 436, 438 for the labels in the label set 232. At block 510, based on the probability scores 434, 436, 438, the transaction may be classified as a normal transaction or an attack transaction.

[0082] Various classification logic processes may be implemented at block 510. For example, Figure 6 A flow chart of a process 600 for classifying transactions according to some embodiments is shown. In instances where a binary classification of transactions as normal transactions or attack transactions is desired, process 600 may be used at block 510 of process 500.

[0083] At block 602, the probability scores 434, 436, 438 of the different tags in the tag set 232 are compared to identify the tag with the highest probability score. If, at block 604, the normal tag has the highest probability score, then, at block 606, the transaction is classified as a normal transaction. If, at block 608, the attack tag has the highest probability score, then, at block 610, the transaction is classified as an attack transaction. If, at block 608, neither the normal tag nor the attack tag has the highest probability score, then the uncertain tag has the highest probability score, and process 600 proceeds to block 612.

[0084] At block 612, the probability scores of the normal and attack labels are compared to determine which label has the second highest probability score (where the uncertain label has the highest score). If, at block 614, the normal label has the second highest probability score, then, at block 616, the transaction is classified as a normal transaction; otherwise, at block 618, the transaction is classified as an attack transaction.

[0085] The decision logic of process 600 can be summarized as follows: If the label with the highest probability score is a normal label or an attack label, the transaction is classified as the corresponding type. If the label with the highest probability score is an uncertain label, the transaction is classified as the type corresponding to the label with the second highest probability score. It should be understood that the classification determined using processes 500 and 600 indicates whether a transaction is more likely to be normal or an attack, and some transactions may be incorrectly classified. As with other fraud detection techniques, machine learning model 200 does not need to be foolproof.

[0086] The final classification determined from process 600 can be used in various ways. For example, the monitoring system 110 can send a report to the requesting server system 104 indicating whether the transaction is classified as normal or an attack. In some embodiments, the probability score 438 of the uncertain label can be provided as the uncertainty score associated with the classification. Other information (e.g., all probability scores 434, 436, 438) can also be included in the report. The server system 104 can use the report to determine whether to allow or deny the ongoing transaction. In some embodiments, the server system 104 can be configured to deny transactions classified as attacks if the uncertainty score is below a threshold, and allow other transactions (assuming the account credentials are valid and meet any other requirements imposed by the server system 104). Optionally, transaction data can be added to a training data set, where the classification is used to apply the label. In some embodiments, for the transaction data with the highest probability score for the uncertain label, the label for training purposes can be set to uncertain.

[0087] Other uses for classification information include analyzing attack frequencies. For example, if the fraction of transactions classified as attacks at a particular server (or across multiple servers) shows an increase, this can indicate that an attack is ongoing, and the targeted server can implement additional security precautions, such as requiring additional verification steps or rejecting all transactions for a period of time.

[0088] Process 600 is illustrative, and other decision logic processes may be used to assign a final classification to a transaction based on the probability scores output from the machine learning model 200. In some embodiments, the monitoring system 110 may provide the probability scores 434, 436, 438 for each tag in the tag set 232 to the server system 104 involved in a given transaction, and the server system 104 may implement process 600 or other processes to determine whether to allow or deny the transaction.

[0089] In some embodiments, a machine learning model similar to machine learning model 200 may be used to distinguish various types of attacks from each other and from normal transactions. Figure 7A simplified block diagram of a machine learning model 700 according to some embodiments is shown. The machine learning model 700 can distinguish between several (N) different types of attacks. To this end, the machine learning model 700 includes a normal generation unit 710 and N separate attack generation units 720-1 to 720-N. Each generation unit can be a VAE (e.g., as described above for the normal generation unit 210 and the attack generation unit 220 of the machine learning model 200) or other generative machine learning (or artificial intelligence) unit, and different generation units in the normal generation unit 710 and the attack generation units 720-1 to 720-N can have the same, similar, or very different internal structures. The normal generation unit 710 can generate a normal reconstruction 718, and each attack generation unit 720-1 to 720-N can generate an attack reconstruction 728-1 to 728-N. To the extent that different types of attacks have differences in their characteristics, the attack reconstructions 728-1 to 728-N will be different from each other and from the normal reconstruction 718. The combine gate 708 can combine or concatenate the normal reconstruction 718 and the attack reconstructions 728-1 to 728-N with the input transaction data 702, similar to the combine gate 208 described above. The multi-label classifier unit 730 can be a feed-forward neural network or other machine learning classifier (similar to the multi-label classifier unit 230 described above) that is trained to assign a probability score to each of a number of labels 732, including a normal label 734, an uncertain label 736, and a set of N attack labels 738-1 to 738-N corresponding to the number of different types of attacks to be distinguished. The routing gate 704 can be used to route the transaction data 702 to one or more of the normal generation unit 710 and the attack generation units 720-1 to 720-N. For example, in training mode, routing gate 704 can operate similarly to label gate 204 and selection gate 206 of machine learning model 200, where labeled transaction data 702 is routed to a corresponding one of generation units 710, 720-1 to 720-N, and null vectors are routed to all other generation units 710, 720-1 to 720-N, while unlabeled transaction data 702 can be randomly routed based on the probability of each different type of attack. For example, a random exit gate or random selection gate (similar to selection gate 206) described above can be implemented, where the probability of a particular route depends on the fraction of transactions expected to be a particular type of attack.

[0090] The training of the machine learning model 700 can be performed similarly to the training of the machine learning model 200 described above, with an appropriately modified loss function. In inference mode, the routing gate 704 can route input transaction data to all normal generation units 710 and attack generation units 720-1 to 720-N.

[0091] In this way, any number and combination of attack types can be distinguished. For example, an enumeration attack may be different from an account testing attack. The number and combination of attack types in a particular embodiment can be chosen based on design considerations such as available resources (because each generation unit may be computationally intensive), the ability to detect or define the distinction between different types of attacks, and the availability of training data for each type of attack.

[0092] Additional Examples

[0093] Although the present invention has been described with reference to specific embodiments, those skilled in the art will appreciate that variations and modifications are possible. For example, different machine learning models or algorithms can be used, including any type of generative model and / or any type of multi-label (or multi-class) classifier model. Different types of generative models can be used in any combination for different transaction types. The training data can include data from any number of transactions and can initially include any combination of labeled and / or unlabeled transactions, including cases where no training data is initially labeled as an attack or normal transaction. As described above, labels can be added or updated during training, thereby increasing the availability of labeled training data as training proceeds. (Note that initially including at least some labeled transactions in the training data set can achieve more efficient training; however, initial labeling is not required.) The machine learning model can be retrained from time to time (e.g., daily, weekly, monthly, or annually) as new data becomes available. In some embodiments, old data points can expire and be removed from the training set before retraining.

[0094] The type of integrated machine learning models described herein can be used to distinguish between legitimate transactions and attack transactions in a variety of scenarios. Examples include enumeration attacks, in which an attacker attempts to guess credentials (e.g., a password or account number), and / or test attacks, in which an attacker attempts to determine whether credentials they have obtained are valid. In some embodiments, multiple types of attacks can be distinguished. As described above, a machine learning model can be constructed for transactions on a single server or for transactions on multiple servers.

[0095] The classification information generated by the machine learning model, including probability scores for various labels and / or the final classification of transactions as attacks or normal, can be used in various applications. For example, as described above, the classification information can be used to determine whether to allow or deny transactions in progress at a server. In addition, the classification information can be accumulated over time, for example by monitoring system 110, and can be used to monitor attack activity at one or more server systems. For example, when an attack is in progress, the score of transactions classified as attacks can increase. When an increase or decrease in attack activity is detected, monitoring system 110 can alert one or more server systems 104 of the increased or decreased threat level, and server systems 104 can dynamically adjust security measures based on the threat level.

[0096] All processes described herein are illustrative and subject to modification. To the extent logic permits, operations may be performed in an order different from that described; operations described above may be omitted or combined; and operations not explicitly described above may be added.

[0097] It should be understood that any embodiment of the present invention can be implemented in the form of control logic using hardware (e.g., an application specific integrated circuit or a field programmable gate array) and / or using computer software, wherein a general-purpose programmable processor is modular or integrated. As used herein, a processor includes a single-core processor, a multi-core processor on the same integrated chip, or a plurality of processing units on a single circuit board or networked. Based on the present disclosure and the teachings provided herein, those of ordinary skill in the art will know and understand other ways and / or methods of implementing embodiments of the present invention using hardware and combinations of hardware and software.

[0098] Any of the software components or functions described in this application can be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable storage medium; suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, or optical media such as a compact disk (CD) or digital versatile disk (DVD), flash memory, and the like. The computer-readable storage medium can be any combination of one or more such storage devices, and suitable media can be packaged with compatible devices. Any such computer-readable storage medium can reside on or within a single computer product (e.g., a hard drive, CD, or an entire computer system), and can be present on or within different computer products within a system or network.

[0099] Such a program may also be encoded and transmitted using a carrier signal suitable for transmission via a wired network, an optical network, and / or a wireless network conforming to a variety of protocols, including the Internet. In this way, a data signal encoded with such a program (e.g., downloaded via the Internet) may be used to create a computer-readable transmission medium. It should be understood that transmission media are transitory and are distinct from non-transitory computer-readable storage media.

[0100] Any method described herein can be performed in whole or in part with a computer system comprising one or more processors, which can be configured to, for example, perform steps by providing suitable program codes for execution by the processors. Therefore, embodiments may relate to a computer system configured to perform the steps of any method described herein, which may have different components for performing the corresponding steps or groups of corresponding steps. Although presented in numbered steps or blocks, the steps of the method described herein can be performed simultaneously or in different orders. In addition, parts of these steps can be used together with parts of other steps of other methods. In addition, all or part of the steps can be optional. In addition, some or all of the steps of any method can be performed with logic modules, circuits, or other components for performing these steps.

[0101] Although various components are described herein with reference to specific blocks, it should be understood that these blocks are defined for ease of description and are not intended to imply a specific physical arrangement of the components. Blocks do not necessarily correspond to physically different components, and the same physical components can be used to implement aspects of multiple blocks. Components described as dedicated or fixed-function circuits can be configured to perform operations by providing a suitable arrangement of circuit components (e.g., logic gates, registers, switches, etc.); automated design tools can be used to generate a suitable arrangement of circuit components that implement the operations described herein. Components described as processors or microprocessors can be configured to perform the operations described herein by providing suitable program code. Depending on how the initial configuration is obtained, the various blocks may or may not be reconfigurable. Embodiments of the present invention may be implemented in a variety of devices including electronic devices implemented using a combination of circuits and software.

[0102] Unless expressly indicated to the contrary, the recitation of "a" or "the" is intended to mean "one or more." Unless expressly indicated to the contrary, the use of "or" is intended to mean an inclusive or rather than an exclusive or.

[0103] All patents, patent applications, publications, and descriptions mentioned herein are incorporated by reference in their entirety for all purposes. No admission is made that they are prior art.

[0104] The above description is illustrative and not restrictive. After reading this disclosure, many variations of the present invention will become apparent to those skilled in the art. Therefore, the scope of patent protection should not be determined with reference to the above description, but should be determined with reference to the attached claims and their full scope or equivalents.

Claims

1. A computer-implemented method comprising: Obtain transaction data for the transaction; The transaction data is provided as input data to a machine learning model that has been trained to classify transactions using a set of labels, wherein the set of labels includes a first label indicating a normal transaction type, a second label indicating an attack transaction type, and a third label indicating an uncertain type of transaction, wherein the machine learning model includes: a plurality of generation units including a first generation unit associated with the normal transaction type and a second generation unit associated with the attack transaction type, wherein each of the generation units receives the input data and outputs a reconstruction of the input data, wherein the generation units operate independently of one another; a combining gate that generates intermediate data by combining corresponding reconstruction outputs from the plurality of generating units with the input data; and a multi-label classifier unit that determines a probability score for each of the labels in the set of labels based on the intermediate data; and The transaction is classified as a normal transaction or an attack transaction based at least in part on the probability score for each of the tags in the set of tags.

2. The method according to claim 1, further comprising: obtaining a training dataset comprising transaction data of a plurality of transactions, wherein at least some of the transaction data in the training dataset is initially unlabeled; as well as Using the training dataset to train the machine learning model, Wherein training the machine learning model comprises: directing the transaction data having the first tag to the first generating unit; directing the transaction data having the second tag to the second generating unit; and Unlabeled transaction data and transaction data with the third label are randomly directed to one or more of the generation units.

3. The method of claim 2, wherein some of the transaction data in the training dataset are initially labeled.

4. The method of claim 2 , wherein the training of the machine learning model comprises a plurality of training epochs, and wherein at the end of each training epoch, an updated label is assigned to the transaction data of at least one of the transactions in the training dataset based on the probability score determined by the multi-label classifier unit.

5. The method of claim 1 , wherein classifying the transaction comprises: determining which label in the set of labels has a highest probability score; In a case where the first tag has the highest probability score, classifying the transaction as a normal transaction; In a case where the second tag has the highest probability score, classifying the transaction as an attack transaction; and In the case where the third label has the highest probability score: determining which tag in the set of tags has a second highest probability score; When the first tag has the second high probability score, classifying the transaction as a normal transaction; as well as In a case where the second tag has the second high probability score, the transaction is classified as an attack transaction.

6. The method according to claim 5, further comprising: An uncertainty score is assigned to the classification of the transaction as a normal transaction or an attack transaction based on the probability score of the third tag.

7. The method of claim 1 , wherein the transaction data is received while a transaction is in progress, and wherein the method further comprises: A determination is made whether to allow or deny the transaction based at least in part on whether the transaction is classified as a normal transaction or an attack transaction.

8. A computer system comprising: a communication interface for communicating with one or more server systems; a memory for storing transaction data of a plurality of previous transactions, wherein the plurality of previous transactions includes a plurality of normal transactions and a plurality of attack transactions; as well as a processor coupled to the memory and configured to implement a machine learning model, the machine learning model comprising: a plurality of generation units including a first generation unit associated with a normal transaction type and a second generation unit associated with an attack transaction type, wherein each of the generation units receives input data representing a transaction and outputs a reconstruction of the input data, wherein the generation units operate independently of one another; a combining gate that generates intermediate data by combining corresponding outputs from the plurality of generating units with the input data; and a multi-label classifier unit that determines a probability score for each label in a set of labels based on the intermediate data, wherein the set of labels includes a first label indicating the normal transaction type, a second label indicating the attack transaction type, and a third label indicating an uncertain type of transaction, wherein the processor is further configured to: using the stored transaction data to train the machine learning model; receiving new transaction data from one of the one or more server systems via the communication interface; determining a probability score for each of the tags in the set of tags for the new transaction data using the trained machine learning model; and The transaction is classified as a normal transaction or an attack transaction based at least in part on the probability score for each of the tags in the set of tags.

9. The computer system of claim 8, wherein at least one of the generating units comprises a variational autoencoder.

10. The computer system of claim 8, wherein the multi-label classifier unit comprises a feed-forward neural network having one or more layers.

11. The computer system of claim 8, wherein the transaction data for each transaction includes account credentials provided by a client system to the server system, wherein the normal transaction type corresponds to an authorized use of the account credentials, and wherein the attack transaction type corresponds to an attempted or successful unauthorized use of the account credentials.

12. The computer system of claim 8, wherein the processor is further configured such that training the machine learning model comprises: defining a training dataset using at least a portion of the stored transaction data, wherein the training dataset initially includes at least some transactions having the first label, at least some transactions having the second label, at least some transactions having the third label, and at least some unlabeled transactions; directing transaction data of the transaction having the first tag to the first generating unit; as well as The transaction data having the second tag is directed to the second generating unit.

13. The computer system of claim 12, wherein the processor is further configured such that training the machine learning model comprises: randomly directing each of the transactions having the third tag to one or the other of the first generation unit or the second generation unit; as well as Each of the unmarked transactions is randomly directed to one or the other of the first generation unit or the second generation unit.

14. The computer system of claim 12, wherein the processor is further configured such that training the machine learning model comprises: directing a randomly selected subset of the transactions having the third tag to both the first generation unit and the second generation unit; as well as A randomly selected subset of the unmarked transactions is directed to both the first generation unit and the second generation unit.

15. The computer system of claim 12 , wherein training of the machine learning model comprises a plurality of training epochs, and wherein the processor is further configured such that at the end of each training epoch, updated labels are determined for transactions in the training dataset having the third label and for unlabeled transactions, wherein the updated labels for transactions are determined based on the probability scores determined by the multi-label classifier unit.

16. A computer-readable storage medium having program code instructions stored therein, wherein the program code instructions, when executed by a processor in a computer system, cause the processor to perform a method comprising: Obtain transaction data for the transaction; The transaction data is provided as input data to a machine learning model that has been trained to classify transactions using a set of labels, wherein the set of labels includes a first label indicating a normal transaction type, a second label indicating an attack transaction type, and a third label indicating an uncertain type of transaction, wherein the machine learning model includes: a plurality of generation units including a first generation unit associated with the normal transaction type and a second generation unit associated with the attack transaction type, wherein each of the generation units receives the input data and outputs a reconstruction of the input data, wherein the generation units operate independently of one another; a combining gate that generates intermediate data by combining corresponding outputs from the plurality of generating units with the input data; and a multi-label classifier unit that determines a probability score for each of the labels of the set of labels based on the intermediate data; and The transaction is classified as a normal transaction or an attack transaction based at least in part on the probability score for each of the tags in the set of tags.

17. The computer-readable storage medium of claim 16, wherein the method further comprises: obtaining a training dataset comprising transaction data of a plurality of transactions, wherein at least some of the transaction data in the training dataset is initially unlabeled; as well as Using the training dataset to train the machine learning model, wherein training the machine learning model comprises a plurality of training epochs, and wherein, during each epoch: The transaction data with the first tag is directed to the first generating unit; The transaction data having the second tag is directed to the second generating unit; and Unlabeled transaction data and transaction data with the third label are randomly directed to zero or more generation units among the generation units.

18. The computer-readable storage medium of claim 17, wherein the method further comprises, after each training epoch: applying the machine learning model to the unlabeled transaction data and the transaction data having the third label to determine a probability score for each of the labels in the set of labels; and Updated labels are determined for the unlabeled transaction data and the transaction data having the third label based on the probability score for each of the labels in the set of labels.

19. The computer-readable storage medium of claim 17, wherein the transaction data is received from a server computer, and wherein the method further comprises: A report is transmitted to the server computer, the report indicating whether the transaction is classified as a normal transaction or an attack transaction.

20. The computer-readable storage medium of claim 19, wherein the report further comprises an uncertainty score based on the probability score for the third tag.

Images