Machine learning system

Abstract

A machine learning system for processing data corresponding to an incoming transaction. The machine learning system includes a classification history module including a memory configured to store state data for a plurality of categories indexed by respective category identifiers, where the state data stored in the memory for each category identifier corresponds to a previous transaction associated with an entity and a respective category. The attenuation logic stage is configured to modify the state data stored in the memory based on a time difference between a time of an incoming transaction and a time of a previous transaction. When the memory contains state data of a pair of entities and category identifiers associated with the incoming transaction, a time difference dependent attenuation function is applied to the stored state data to generate an attenuated version. The state data output from the attenuation logic stage is updated using an input tensor generated from data corresponding to the incoming transaction to generate updated state data.

Description

Technical Field

[0001] The present invention relates to a categorical history module for a machine learning system, and in particular to a categorical history module for use in a machine learning system for detecting anomalies in patterns of data, such as detecting fraudulent transactions. Certain examples relate to a machine learning system for use in real-time transaction processing. Background Art

[0002] Digital payments have exploded over the past two decades, with more than three-quarters of global payments using some form of payment card or electronic wallet. Point-of-sale systems are gradually becoming digital and less cash-based. In short, the global commerce system now relies heavily on electronic data processing platforms. This presents many engineering challenges that are not primarily faced by the average (lay) user. For example, digital transactions need to be completed in real time, i.e., with minimal levels of latency experienced by computer devices when making purchases. Digital transactions also need to be secure and resilient to attacks and exploits. The processing of digital transactions is also constrained by the historical development of the global electronic payment system. For example, much of the infrastructure is still configured around models designed for mainframe architectures used more than 50 years ago.

[0003] As digital transactions increase, new security risks become apparent. Digital transactions present new opportunities for fraud and malicious activity. In 2015, it was estimated that 7% of digital transactions were fraudulent, and this number will only increase as more economic activity shifts online. It is estimated that fraud losses are four times the world's population (e.g., in US dollars) and are growing.

[0004] Financial services organizations are coming under increased regulatory scrutiny as traditional fraud prevention methods such as identity authentication (e.g., passwords, digital biometrics, national IDs, etc.) have proven ineffective in preventing fraud vectors such as synthetic identities and scams. These much more complex fraud threat vectors require more analysis in large quantities in very short periods of time (less than 50ms) and are often based on much smaller data sample sizes of the scam or fraud itself. This presents significant technical challenges.

[0005] While risks such as fraud are economic issues for companies involved in commerce, the implementation of technical systems for processing transactions is an engineering challenge. Traditionally, banks, merchants, and card issuers have developed "paper" rules or procedures that are manually implemented by clerks to flag or block certain transactions. As transactions become digital, one approach to building technical systems for processing transactions is to provide these developed standard sets to computer engineers and ask them to implement them using digital representations of transactions, that is, to convert handwritten rules into coded logic statements that can be applied to electronic transaction data. As the volume of digital transactions grows, this traditional approach encounters several problems. First, any application processing needs to be performed in "real time", such as with millisecond delays. Second, thousands of transactions need to be processed per second (e.g., a common "load" may be 1000 to 2000 per second), where the load changes unexpectedly over time (e.g., the introduction of a new product or set of tickets can easily increase the average load level several times). Third, for security reasons, transaction processors and banks' digital storage systems are often isolated or partitioned, whereas digital transactions often involve interconnected networks of commercial systems. Fourth, large-scale analysis of actual reported fraud and predicted fraud is now possible. This shows that traditional fraud detection methods are inadequate; accuracy rates are low, and false positive rates are high. This will have a physical impact on digital transaction processing, with more genuine point of sale and online purchases being rejected, and those who try to exploit new digital systems often going unpunished.

[0006] Over the past few years, more machine learning approaches have been adopted for the processing of transaction data. As machine learning models have matured in academia, engineers have begun to try to apply them to the processing of transaction data. However, this has once again run into problems. Even if engineers are given an academic or theoretical machine learning model and asked to implement it, it is not simple. For example, large-scale transaction processing systems begin to have problems. Machine learning models do not have the luxury of infinite inference time as they do in the laboratory. This means that it is simply not practical to implement certain models in a real-time environment, or they need to be significantly adjusted to allow real-time processing at the scale experienced by real-world servers. In addition, engineers need to deal with the problem of implementing machine learning models on data that is isolated or partitioned based on access security, and in situations where the data is updated at an extremely fast rate. Therefore, the problems faced by engineers building transaction processing systems can be viewed as similar to those faced by network or database engineers; machine learning models need to be applied, but the system throughput and query response time constraints set by the processing infrastructure must be met. There are no simple solutions to these problems. In fact, the fact that many transaction processing systems are confidential, proprietary, and based on old technologies means that engineers do not have the knowledge developed in these adjacent fields and often face challenges unique to the transaction processing field. Furthermore, the field of large-scale practical machine learning remains largely unexperienced, and there are few established design patterns or textbooks that engineers can rely on.

[0007] Fraud detection systems generate risk scores for new transactions in real time (i.e., latency <= 100 milliseconds), where high risk scores indicate the likelihood of fraud, error, or unauthorized use of an account. Financial institutions use these scores in their decision logic when deciding whether to approve a transaction (typically, if the risk score is above a certain threshold, the transaction will be rejected). Financial institutions typically want the set of transactions above a certain risk threshold to contain as high a proportion of fraud as possible (i.e., provide the "highest detection rate"), while keeping the false positive classification rate as low as possible (i.e., provide the "highest precision").

[0008] One method known per se in the art involves using machine learning techniques such as recurrent neural networks (RNNs) to detect anomalies in behavioral patterns. Those skilled in the art will appreciate that the output of an RNN is the next state, and that the next state depends on the previous state and the inputs provided to the RNN. In this way, the state of the RNN is based not only on instantaneous information related to a given transaction, but also on the history of transactions that have occurred before, thus retaining a memory of patterns that have been observed. This can be used to detect abnormal behavior that may indicate fraudulent transactions. The terms "behavior" and "behavioral" are used herein to refer to a pattern of activity or action.

[0009] Such detection of unusual activity can provide an improvement in the security of the system when compared to "traditional" fraud prevention methods (e.g., passwords, digital biometrics, national IDs, etc.) Of course, it will be understood that behavioral pattern analysis techniques can be used in conjunction with one or more of these "traditional" methods as appropriate.

[0010] Typically, a given machine learning system may be configured to process transactions associated with many different entities (e.g., different cardholders). Each entity may have different behavioral patterns, and a history for each entity must typically be kept independently in order to detect behavior that is anomalous to that entity. Therefore, machine learning systems used in high-volume transaction processing pipelines typically store state data for each entity (i.e., cardholder).

[0011] Applicants have recognized that the duration between consecutive transactions for a given entity can vary, often significantly. Therefore, the degree of influence that a previous state should have when determining the legality of a new transaction. Applicants' prior patent applications published as WO / 2022 / 008130 and WO / 2022 / 008131 (each of which is incorporated herein by reference) describe an arrangement in which state data for a given entity decays based on the time period that has passed since the state data was stored (i.e., since the last transaction of the entity).

[0012] Data scientists who build machine learning models typically spend a lot of effort designing the models and extracting machine learning features for those models that produce the best trade-off between detection rate and accuracy.

[0013] However, applicants have recognized that further improvements can be made to the technical systems that perform the correlation analysis. In particular, applicants have recognized that the novelty of an entity's interactions (e.g., the novelty of a relationship between an account holder and a particular merchant) is useful in detecting anomalous behavior. The novelty of buyer-seller interactions is an important signal for maximizing the performance of these scores. Established relationships are a good indication that new activity is genuine (i.e., performed in good faith by the buyer), while novel relationships indicate greater suspicion of new activity (which can often be considered in conjunction with other risk signals).

[0014] The present invention seeks to provide improvements to machine learning systems to automatically extract novelty in, for example, interactions between buyers and sellers. Summary of the invention

[0015] According to a first aspect, embodiments of the present invention provide a machine learning system for processing data corresponding to incoming transactions associated with an entity, the machine learning system comprising a categorical history module configured to process at least some of the data, the categorical history module comprising:

[0016] i) a memory configured to store state data for a plurality of categories indexed by respective category identifiers, wherein the state data stored in the memory for each category identifier corresponds to a previous transaction associated with the entity and the respective category;

[0017] ii) a decay logic stage configured to modify state data stored in the memory based on a time difference between a time of an incoming transaction and a time of a previous transaction, the decay logic stage being configured to:

[0018] a) when the memory contains state data for an entity and category identifier pair associated with an incoming transaction, retrieving the state data and applying a decay function to the state data to generate a decayed version of the state data, wherein the decay function depends on the time difference, and outputting the decayed version of the state data; and

[0019] iii) an update logic stage configured to: update the state data output from the decay logic stage using an input tensor generated from data corresponding to the incoming transaction to generate updated state data; store the updated state data in a memory for an entity and class identifier pair associated with the incoming transaction; and output an output tensor including the updated state data;

[0020] iv) wherein the machine learning system is configured to map the output tensor from the classification history module to a scalar value representing the likelihood that the incoming transaction is an anomaly within the sequence of actions; and

[0021] v) Wherein a scalar value is used to determine whether to approve or reject an incoming transaction.

[0022] The first aspect of the invention also extends to a method of processing data associated with a proposed transaction associated with an entity, the method comprising:

[0023] i) storing in a memory state data for a plurality of categories indexed by respective category identifiers, wherein the state data stored in the memory for each category identifier corresponds to a previous transaction associated with the entity and the respective category;

[0024] ii) modifying state data stored in a memory based on a time difference between a time of an incoming transaction and a time of a previous transaction, wherein the step of modifying the state data comprises:

[0025] a) when the memory contains state data for an entity and class identifier pair associated with an incoming transaction, retrieving the state data and applying a decay function to the state data to generate a decayed version of the state data, wherein the decay function depends on the time difference, and outputting the decayed version of the state data; and

[0026] iii) updating a state data output using an input tensor generated from data corresponding to an incoming transaction to generate updated state data; storing the updated state data in a memory for an entity and class identifier pair associated with the incoming transaction; and outputting an output tensor including the updated state data;

[0027] iv) mapping the output tensor to a scalar value representing the likelihood that the incoming transaction is an anomaly within the action sequence; and

[0028] v) Use the scalar value to determine whether to approve or reject the incoming transaction.

[0029] The first aspect of the invention also extends to a non-transitory computer readable medium comprising instructions which, when executed by a processor, cause the processor to perform a method of processing data associated with a proposed transaction associated with an entity, the method comprising:

[0030] i) storing in a memory state data for a plurality of categories indexed by respective category identifiers, wherein the state data stored in the memory for each category identifier corresponds to a previous transaction associated with the entity and the respective category;

[0031] ii) modifying state data stored in a memory based on a time difference between a time of an incoming transaction and a time of a previous transaction, wherein the step of modifying the state data comprises:

[0032] a) when the memory contains state data for an entity and class identifier pair associated with an incoming transaction, retrieving the state data and applying a decay function to the state data to generate a decayed version of the state data, wherein the decay function depends on the time difference, and outputting the decayed version of the state data; and

[0033] iii) updating a state data output using an input tensor generated from data corresponding to an incoming transaction to generate updated state data; storing the updated state data in a memory for an entity and class identifier pair associated with the incoming transaction; and outputting an output tensor including the updated state data;

[0034] iv) mapping the output tensor to a scalar value representing the likelihood that the incoming transaction is an anomaly within the action sequence; and

[0035] v) Use the scalar value to determine whether to approve or reject the incoming transaction.

[0036] The first aspect of the invention also extends to a computer software product comprising instructions which, when executed by a processor, cause the processor to perform a method of processing data associated with a proposed transaction associated with an entity, the method comprising:

[0037] i) storing in a memory state data for a plurality of categories indexed by respective category identifiers, wherein the state data stored in the memory for each category identifier corresponds to a previous transaction associated with the entity and the respective category;

[0038] ii) modifying state data stored in a memory based on a time difference between a time of an incoming transaction and a time of a previous transaction, wherein the step of modifying the state data comprises:

[0039] a) when the memory contains state data for an entity and class identifier pair associated with an incoming transaction, retrieving the state data and applying a decay function to the state data to generate a decayed version of the state data, wherein the decay function depends on the time difference, and outputting the decayed version of the state data; and

[0040] iii) updating a state data output using an input tensor generated from data corresponding to an incoming transaction to generate updated state data; storing the updated state data in a memory for an entity and class identifier pair associated with the incoming transaction; and outputting an output tensor including the updated state data;

[0041] iv) mapping the output tensor to a scalar value representing the likelihood that the incoming transaction is an anomaly within the action sequence; and

[0042] v) Use the scalar value to determine whether to approve or reject the incoming transaction.

[0043] It will therefore be appreciated that embodiments of the present invention provide an improved arrangement in which state data relating to previous transactions of matching categories is stored in memory, and the next time there is a transaction matching a given category for the same entity (i.e., for a pair of entity and category identifiers associated with a newly incoming transaction), the stored state data for the given category is retrieved. The categories that may be used are described in further detail below, however, in general, the categories may include, for example, merchants, merchant types, transaction amounts, time of day, or some combination of these.

[0044] Thus, the classification history module provides a mechanism for tracking patterns across transactions of a particular category. Unlike conventional mechanisms such as time-decayed units that typically retrieve state from a previous transaction (i.e., the immediately preceding transaction for that entity), the classification history module selectively retrieves state data corresponding to the same category as the current transaction, which may not be the most recent transaction, and a significant period of time may have passed since the last transaction of that category was processed, during which any number of intervening transactions corresponding to other categories occurred concurrently. This allows for the extraction of signals that provide information about the novelty of an entity's interaction with a particular category, where such novelty—or a behavioral pattern associated with that novelty—can be indicative of anomalous behavior (e.g., fraud).

[0045] Advantageously, embodiments of the present invention may provide significant improvements in speed and / or confidentiality of implementation. Specifically, data scientists no longer need to manually design features of this type, which means that they do not need to be exposed as input to the classifier for model management, and the implementation time of the model may be reduced.

[0046] Embodiments of the present invention may also advantageously provide improvements in detection performance. The classification history module may learn more subtle interaction logic than a human could manually design in a limited time. Specifically, the classification history module may learn that only certain types of activity qualify as trust building for scoring the current type of activity. Applicants have found that use of the present invention generally translates into significant detection enhancements relative to methods that may be known per se in the art.

[0047] Embodiments of the present invention can be applied to a variety of digital transactions, including but not limited to card payments, so-called "wire transfers", peer-to-peer payments, bank's automated clearing system (BACS) payments, and automated clearing house (ACH) payments. The output of the machine learning system can be used to prevent a variety of fraud and crime, such as card fraud, application fraud, payment fraud, merchant fraud, gaming fraud, and money laundering.

[0048] As outlined above, the classification history module retrieves state data corresponding to the same category as the incoming transaction. Typically, the memory can store state data for each possible category (e.g., each merchant or each merchant type), however, in practice, this may not be the case. For example, a limit may be imposed on the number of categories of state data that can be stored in the memory. This may be due to hardware or software limitations of a given implementation, or it may be a design decision to limit the amount of state data retained to a certain number. Therefore, it is possible that an incoming transaction may correspond to a category for which there is no existing state data for a corresponding category identifier stored in the memory at this time. In some embodiments, the decay logic stage is also configured to:

[0049] When the memory does not contain state data for an entity and class identifier pair associated with an incoming transaction, new state data is generated and output. For example, the new state data may typically include a zero tensor—however, it will be understood that some other default tensor may be used for the new state data if appropriate.

[0050] Typically, data from incoming transactions can be converted into an input tensor suitable for input to the rest of the machine learning system. Those skilled in the art will appreciate that the input tensor can be viewed as a feature tensor or vector, i.e., a tensor of values, where each value corresponds to the degree to which the incoming transaction has certain features. In some embodiments, the machine learning system also includes: a first neural network level, which is configured to apply a neural network layer with a corresponding plurality of learned weights to the data corresponding to the incoming transaction to generate an input tensor, and provide the input tensor to the update logic level of the classification history module. In other words, the first neural network can be described as an embedding layer. In some embodiments, the first neural network can include a first multilayer perceptron (MLP).

[0051] Similarly, the output tensor produced by the update logic stage is mapped to a scalar value, as outlined above. In some embodiments, the machine learning system further comprises: a second neural network stage configured to apply a second neural network layer having a corresponding plurality of learned weights to the output tensor generated by the update logic stage of the classification history module to generate a scalar value representing the likelihood that an incoming transaction presents an anomaly within the action sequence. In some embodiments, the second neural network may comprise a second multilayer perceptron (MLP).

[0052] Those skilled in the art will appreciate that an MLP is a feedforward neural network that is typically constructed from at least an input layer, a hidden layer, and an output layer, wherein each layer includes a plurality of nodes. The hidden layer and output layer nodes have activation functions (e.g., nonlinear activation functions). Nodes from each layer are connected to nodes in a subsequent layer with certain weights (typically each node in a layer is connected to each node in the next layer). These weights can be learned during a training phase (e.g., during supervised learning), such as via back propagation.

[0053] In some embodiments, the update logic stage includes: a third neural network stage configured to generate updated state data using the decayed state data and an input tensor derived from an incoming transaction. In other words, the updated state data may also be generated by a neural network layer. The neural network layer may also use trained weights. In some embodiments, the third neural network stage may include a recursive neural network.

[0054] The amount of time that passes between consecutive transactions for a given entity (e.g., a cardholder) belonging to a particular category may vary significantly. For example, if the categories include merchant identities and state data is stored for each merchant (i.e., state data from previous buyer-seller interactions involving the cardholder and the merchant), it may appear that the card may be used several times a week by one merchant, while the same card may go weeks or months between transactions at another merchant. Similarly, different entities may have transactions conducted at very different rates, and the behavioral patterns of any given entity may vary over time.

[0055] It has been appreciated that the amount of time that has elapsed since relevant state data retrieved from memory for a particular entity and category combination of an incoming transaction was stored can have a significant impact on its relevance when determining the legitimacy of a new incoming transaction.The decay logic stage modifies the state data to reduce its impact.

[0056] A decay function is used to reduce the impact of previous state data based on how old it is. In one set of embodiments, the decay logic stage is configured to modify the state data of an entity associated with an incoming transaction stored in memory based on the time difference between the time of the incoming transaction and the time of the most recent transaction of the entity. In other words, in such embodiments, each time there is a transaction for the entity, the entire state data table of the entity is decayed. Advantageously, the method does not require any record keeping of the time when each category of the entity was last seen, but rather uses a single timestamp for each entity, where the timestamp corresponds to the last transaction of the entity (regardless of which category the transaction is associated with). In some such embodiments, the memory is configured to store a timestamp of the state data stored in the memory for each entity. Decaying the state table of a particular entity can advantageously reduce latency (compared to decaying the tables of all entities) while eliminating the need to store timestamps for each entity-class pair (as in the case where only the state data of a particular entity-class pair is decayed, as outlined below with respect to a set of alternative embodiments).

[0057] In an alternative set of embodiments, the decay logic stage is configured to modify all state data for each entity stored in memory based on the time difference between the time of an incoming transaction and the time of the immediately preceding transaction. In other words, in such embodiments, each time there is a transaction, the entire state data table for all entities is decayed using the timestamp associated with the last transaction (regardless of who that transaction involved), regardless of which entity the transaction was for. However, it will be appreciated that this may impose significant computational requirements to mitigate unnecessary delay increases.

[0058] In another set of alternative embodiments, the decay logic stage is configured to modify only the state data stored in the memory for the entity and category identifier pair associated with an incoming transaction, wherein the decay logic stage modifies the state data based on the time difference between the time of the incoming transaction and the time of the previous transaction of the entity and category identifier pair associated with the incoming transaction. Under this arrangement, each time there is a transaction for a particular entity and category combination, only the state data for that combination is decayed. In some such embodiments, the memory is configured to store a timestamp for each state data stored in the memory. The timestamp may form part of the state data or may be stored separately. Advantageously, the method does not require the entire table to be decayed for each transaction, which may enable faster processing at the trade-off of increased memory usage to store timestamps.

[0059] There are multiple options for implementing the storage of state data in the memory. However, in some embodiments, the memory is configured as a stack so that retrieved state data is removed from the stack and so that updated state data is stored at the top of the stack. According to such embodiments, the most recent entity-class interactions may be at the top of the stack, while the least recent interactions are at the bottom of the stack.

[0060] In some embodiments, the classification history module is configured such that when the memory is full, the state data stored for at least one category identifier is erased. In some such embodiments, the classification history module is configured such that when the memory is full, the state data stored for the least recently seen category identifier is erased. Under such an arrangement, the oldest data is "discarded" from the memory to make room for new data. In effect, this provides an additional "forgetting" function, wherein, assuming the memory size is appropriately selected, data that is too old is removed. Typically, the size of the memory can be selected to ensure that data that is desired to be retained is not routinely erased from the memory.

[0061] In some embodiments, the state data stored for each entity and category identifier pair includes a tensor of values. Each value in the tensor may correspond to some feature or combination of features that a transaction may have, where the magnitude of the value provides a measure of the strength with which the transaction (or pattern of previous transactions) exhibits those features.

[0062] In some such embodiments, the decay function applies a corresponding decay multiplier (e.g., exponential decay) to each value in the value. It will be understood that different multipliers (e.g., different exponential decays) may be applied to each value. Using different decay multipliers for different values ​​enables the strength of memory to be set differently for different features. It may be desirable to retain the history of certain features for a longer period of time than other features. For example, the state data may be related to (i.e., dependent on) the average transaction amount of transactions for entity and category identifier pairs, and it may be useful to keep the impact of the average for several months (e.g., 6 months or 12 months) at a time. At the same time, state data that depends on transaction speed (i.e., transaction rate per unit time) may be of interest in a shorter period of time (e.g., in the course of 1 or 2 hours), and it may therefore be preferred to limit its impact outside such a period of time. It will be understood that in practice, the values ​​stored in the state data may not have a direct (i.e., one-to-one) correspondence with any one or more specific features, but each value is a function of one or more features. In other words, the numerical values ​​generated (e.g., via a neural network layer) are stored as state data, and each numerical value may have a complex dependency on multiple features. The relationship between these features and the corresponding state data values ​​(i.e., numerical values) attributed thereto can be learned during training. Thus, it should be understood that there is not necessarily any user-specified state data decay associated with any particular feature, but rather the machine learning system can learn that historical state data derived from certain features (such as the examples previously described) or combinations of such features should be retained longer than other data.

[0063] The decay multipliers may be appropriately selected to appropriately tailor the degree of memory preservation for each feature. In at least some embodiments, these decay multipliers may be predetermined, i.e., they may be pre-set. According to some such embodiments, the machine learning system may learn that values ​​derived from certain features or combinations of features should be subjected to one or more of these decay factors to varying degrees, i.e., the decay factors affect the end-to-end training process.

[0064] However, in some embodiments, at least some (and possibly all) of the decay multipliers may be learned. Rather than providing a selection of decay factors in advance, a machine learning system may learn on its own the best decay factors to use and what state data those learned decay factors should be used for.

[0065] Typically, the decay multiplier may be arranged as a tensor (or vector, etc.) so that the time decay may be element-wise multiplied with the state data to be decayed. Where the categorical state data is stored in a table and each column in the table may be indexed by a category identifier, the time decay tensor (or vector, etc.) may be element-wise multiplied with each column of the table. It will of course be understood that the table may equivalently be configured so that the state data is stored in rows indexed by the category identifier.

[0066] As outlined above, the classification history module provides patterns across transactions for specific entity and category pairs to be retained. In some embodiments, the machine learning system further comprises: a time decay unit module configured to process at least some of the data corresponding to the incoming transactions, the time decay unit module comprising:

[0067] a second memory configured to store second state data corresponding to an immediately preceding transaction; and

[0068] and a second decay logic stage configured to modify the second state data stored in the second memory based on a time difference between the time of the incoming transaction and the time of the immediately preceding transaction. Those skilled in the art will appreciate that, unlike the categorized history module, the time decay unit module operates on a transaction-by-transaction basis for a particular entity, regardless of the categories to which those transactions relate.

[0069] According to such an embodiment, the classification history module and the time decay unit module can be arranged in parallel with each other and provide complementary analysis of incoming transactions. The classification history module helps detect anomalies (such as fraud) based on the novelty of the interaction between the entity (such as cardholder) and the category (such as merchant, merchant type, time of day, transaction amount, etc.), while the time decay unit module helps detect anomalies based on the entity's recent transaction behavior across all categories.

[0070] In some such embodiments, the time decay unit module further comprises:

[0071] a fourth neural network stage configured to determine next state data using the previous state data modified by the second decay logic stage and a second input tensor derived from the incoming transaction, the fourth neural network stage configured to store the next state data in a second memory. In some embodiments, the fourth neural network stage may include a recurrent neural network.

[0072] In embodiments where both a classification history module and a time decay unit are provided, data corresponding to incoming transactions is provided to each of the classification history module and the time decay unit. Each of these modules may receive different data, or there may be some (or perhaps complete) overlap in the data received by each module. Typically, it is expected that the two modules will act on different features, and therefore the data provided to each module may be specific to the respective module.

[0073] In the case where a neural network layer (e.g., MLP) with learned weights is used to generate an input tensor from incoming transactions, the same neural network layer can generate the input tensor such that a first portion of the input tensor is provided to a classification history module and a second portion of the input tensor is provided to a time decay unit module.

[0074] In some embodiments using a time decay unit module, the machine learning system is configured to map output data from both the time decay unit module and the classification history module to a scalar value representing the likelihood that an incoming transaction presents an anomaly within a sequence of actions.

[0075] In some embodiments, the memory is configured to store state data for a plurality of entities, wherein, for each entity, a plurality of categories indexed by corresponding category identifiers are stored, wherein the state data stored in the memory for each category identifier corresponds to a previous transaction associated with the corresponding entity and the corresponding category.

[0076] It will be understood that "categories" as referred to herein relate to some aspects of a transaction, that is, a category may be viewed as a group or label that may be applied to transactions that meet some criteria. For example, a category may represent different secondary entities (e.g., merchants) with which an entity (or "primary" entity, which may be, for example, a cardholder) transacts. Many different categories may be used. In some embodiments, each of a plurality of categories includes one or more of: secondary entity; secondary entity type; transaction value; transaction value band; day of the week; time of day; hour of day; and time window. In a particular set of embodiments, a plurality of categories may include a composite of one or more of these categories.

[0077] When viewed from a second aspect, embodiments of the invention provide a method of processing data associated with a proposed transaction, the method comprising:

[0078] receiving an incoming event from a client transaction processing system, the incoming event being associated with a request for an approval decision for a proposed transaction;

[0079] Parsing incoming events to extract data for a proposed transaction, including determining a time difference between the proposed transaction and a prior transaction;

[0080] Applying the machine learning system of an embodiment of the first aspect of the invention to output a scalar value representing a likelihood that a proposed transaction presents an anomaly within a sequence of actions based on the extracted data and the time difference, the application comprising accessing a memory to retrieve at least state data of an entity and a category identifier associated with the transaction;

[0081] determining a binary output based on a scalar value output by the machine learning system, the binary output representing whether the proposed transaction is approved or denied; and

[0082] Returns the binary output to the client transaction processing system.

[0083] A second aspect of the invention extends to a non-transitory computer readable medium comprising instructions which, when executed by a processor, cause the processor to perform a method of processing data associated with a proposed transaction, the method comprising:

[0084] receiving an incoming event from a client transaction processing system, the incoming event being associated with a request for an approval decision for a proposed transaction;

[0085] Parsing incoming events to extract data for a proposed transaction, including determining a time difference between the proposed transaction and a prior transaction;

[0086] Applying the machine learning system of an embodiment of the first aspect of the invention to output a scalar value representing a likelihood that a proposed transaction presents an anomaly within a sequence of actions based on the extracted data and the time difference, the application comprising accessing a memory to retrieve at least state data of an entity and a category identifier associated with the transaction;

[0087] determining a binary output based on a scalar value output by the machine learning system, the binary output representing whether the proposed transaction is approved or denied; and

[0088] Returns the binary output to the client transaction processing system.

[0089] A second aspect of the invention extends to a computer software product comprising instructions which, when executed by a processor, cause the processor to perform a method of processing data associated with a proposed transaction, the method comprising:

[0090] receiving an incoming event from a client transaction processing system, the incoming event being associated with a request for an approval decision for a proposed transaction;

[0091] Parsing incoming events to extract data for a proposed transaction, including determining a time difference between the proposed transaction and a prior transaction;

[0092] Applying the machine learning system of an embodiment of the first aspect of the invention to output a scalar value representing a likelihood that a proposed transaction presents an anomaly within a sequence of actions based on the extracted data and the time difference, the application comprising accessing a memory to retrieve at least state data of an entity and a category identifier associated with the transaction;

[0093] determining a binary output based on a scalar value output by the machine learning system, the binary output representing whether the proposed transaction is approved or denied; and

[0094] Returns the binary output to the client transaction processing system.

[0095] The classification history module is novel and inventive in itself and therefore, when viewed from a third aspect, embodiments of the invention provide a classification history module for use in a machine learning system for processing data corresponding to incoming transactions associated with an entity, the classification history module being configured to process at least some of the data, the classification history module comprising:

[0096] i) a memory configured to store state data for a plurality of categories indexed by respective category identifiers, wherein the state data stored in the memory for each category identifier corresponds to a previous transaction associated with the entity and the respective category;

[0097] ii) a decay logic stage configured to modify the state data stored in the memory based on a time difference between the time of the incoming transaction and the time of the previous transaction, the decay logic stage being configured to:

[0098] a) when the memory contains state data for an entity and class identifier pair associated with an incoming transaction, retrieving the state data and applying a decay function to the state data to generate a decayed version of the state data, wherein the decay function depends on the time difference, and outputting the decayed version of the state data; and

[0099] iii) an update logic stage configured to: update state data output from the decay logic stage using an input tensor generated from data corresponding to an incoming transaction to generate updated state data; store the updated state data in a memory for an entity and category identifier pair associated with the incoming transaction; and output an output tensor including the updated state data.

[0100] A third aspect of the invention further extends to a method of processing data associated with a proposed transaction associated with an entity, the method comprising:

[0101] i) storing in a memory state data for a plurality of categories indexed by respective category identifiers, wherein the state data stored in the memory for each category identifier corresponds to a previous transaction associated with the entity and the respective category;

[0102] ii) modifying state data stored in a memory based on a time difference between a time of an incoming transaction and a time of a previous transaction, wherein the step of modifying the state data comprises:

[0103] a) when the memory contains state data for an entity and class identifier pair associated with an incoming transaction, retrieving the state data and applying a decay function to the state data to generate a decayed version of the state data, wherein the decay function depends on the time difference, and outputting the decayed version of the state data; and

[0104] iii) updating a state data output using an input tensor generated from data corresponding to an incoming transaction to generate updated state data; storing the updated state data in a memory for an entity and class identifier pair associated with the incoming transaction; and outputting an output tensor including the updated state data;

[0105] A third aspect of the invention also extends to a non-transitory computer readable medium comprising instructions which, when executed by a processor, cause the processor to perform a method of processing data associated with a proposed transaction associated with an entity, the method comprising:

[0106] i) storing in a memory state data for a plurality of categories indexed by respective category identifiers, wherein the state data stored in the memory for each category identifier corresponds to a previous transaction associated with the entity and the respective category;

[0107] ii) modifying state data stored in a memory based on a time difference between a time of an incoming transaction and a time of a previous transaction, wherein the step of modifying the state data comprises:

[0108] a) when the memory contains state data for an entity and class identifier pair associated with an incoming transaction, retrieving the state data and applying a decay function to the state data to generate a decayed version of the state data, wherein the decay function depends on the time difference, and outputting the decayed version of the state data; and

[0109] iii) updating a state data output using an input tensor generated from data corresponding to an incoming transaction to generate updated state data; storing the updated state data in a memory for an entity and class identifier pair associated with the incoming transaction; and outputting an output tensor including the updated state data.

[0110] The third aspect of the invention also extends to a computer software product comprising instructions which, when executed by a processor, cause the processor to perform a method of processing data associated with a proposed transaction associated with an entity, the method comprising:

[0111] i) storing in a memory state data for a plurality of categories indexed by respective category identifiers, wherein the state data stored in the memory for each category identifier corresponds to a previous transaction associated with the entity and the respective category;

[0112] ii) modifying state data stored in a memory based on a time difference between a time of an incoming transaction and a time of a previous transaction, wherein the step of modifying the state data comprises:

[0113] a) when the memory contains state data for an entity and class identifier pair associated with an incoming transaction, retrieving the state data and applying a decay function to the state data to generate a decayed version of the state data, wherein the decay function depends on the time difference, and outputting the decayed version of the state data; and

[0114] iii) updating a state data output using an input tensor generated from data corresponding to an incoming transaction to generate updated state data; storing the updated state data in a memory for an entity and class identifier pair associated with the incoming transaction; and outputting an output tensor including the updated state data;

[0115] It will be appreciated that the optional features described above in relation to embodiments of the first aspect of the invention are equally applicable to the second and third aspects of the invention, where technically appropriate.

[0116] Where technically appropriate, embodiments of the invention may be combined. Embodiments are described herein as comprising certain features / elements. The disclosure also extends to separate embodiments consisting of or essentially consisting of said features / elements.

[0117] Technical references such as patents and applications are incorporated herein by reference.

[0118] Any embodiment specifically and explicitly recited herein may form the basis for a disclaimer either alone or in combination with one or more further embodiments.

[0119] In the context of this specification, “comprising” should be interpreted as “including.” Aspects of the invention comprising certain elements are also intended to extend to alternative embodiments “consisting of” or consisting essentially of the relevant elements.

[0120] The term "memory" should be understood to mean any device suitable for storing data, and includes volatile and non-volatile memory as appropriate for the intended application. Those skilled in the art will appreciate that this includes, but is not limited to, random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), magnetic storage, solid-state storage, and flash memory. It will be understood that a combination of one or more of these may also be used to store data where technically appropriate (e.g., using faster access volatile memory for frequently accessed data).

[0121] The term "data" used in different contexts herein refers to digital information, such as digital information represented by a known bit structure in one or more programming languages. In use, data may refer to digital information stored in a computer memory as a sequence of bits. Certain machine learning models may operate on structured data arrays in a predefined bit format. Those skilled in the art will readily appreciate that these may be referred to as arrays, multidimensional arrays, matrices, vectors, tensors, or other such similar terms. It should be noted that for machine learning methods, multidimensional arrays or tensors (e.g., having a defined range in multiple dimensions) may be "flattened" to be represented (e.g., in memory) as a sequence or vector of values ​​stored according to a predefined format (e.g., n-bit integers or floating point numbers, signed or unsigned). Therefore, the term "tensor" used herein encompasses multidimensional arrays (e.g., vectors, matrices, volume arrays, etc.) having one or more dimensions.

[0122] Regardless of the specific data format selected, the principles of the present invention apply. Data can be represented as an array, vector, tensor, or any other suitable format. For ease of reference, these terms are used interchangeably herein, and references to "vectors" or "multiple vectors" of values ​​should be understood as appropriately extended to a tensor or multiple tensors of any n-dimensional value. Similarly, references to "tensors" or "multiple tensors" of values ​​should be understood as extended to vectors, which are understood by those skilled in the art to be only one-dimensional tensors. Regardless of the format of the data structure for the arrays of these values, the principles of the present invention can be applied. For example, state data can be stored in a memory as a one-dimensional tensor (i.e., vector) or as a tensor with two or more dimensions (i.e., multiple tensors), and those skilled in the art will readily understand that data processing elements can be appropriately modified to process the selected data format. The relative positions between the various state values, such as how they are sorted within a vector or tensor, are generally not important, and the scope of the present invention is not limited to any specific data format or structure.

[0123] The term "structured digital representation" is used to refer to digital data in a structured form, such as an array of one or more dimensions storing numerical values ​​of a common data type (such as integers or floating point values). Structured digital representations may include vectors or tensors (as used in machine learning terminology). Structured digital representations are typically stored as a set of indices and / or contiguous memory locations, for example a one-dimensional array of 64-bit floating points may be represented in computer memory as a contiguous sequence of 64-bit memory locations in a 64-bit computing system.

[0124] The term "transaction data" as used herein refers to electronic data associated with a transaction. A transaction includes a series of communications between different electronic systems to effectuate a payment or exchange. Typically, transaction data may include data indicating events related to transaction processing (e.g., actions taken in a timely manner), and may provide information for transaction processing. Transaction data may include structured, unstructured, and semi-structured data or any combination thereof. Transaction data may also include data associated with a transaction, such as data used to process a transaction. In some cases, transaction data may be broadly used to refer to actions taken against one or more electronic devices. Depending on the specific implementation, transaction data may take a variety of forms. However, different data types and formats may be appropriately converted by pre-processing or post-processing.

[0125] The term "interface" as used herein refers to any physical and / or logical interface that allows one or more of data input and data output. The interface can be implemented by a network interface suitable for sending and / or receiving data, or by retrieving data from one or more memory locations, such as by a processor executing an instruction set. The interface may also include a physical (network) coupling through which data is received, such as hardware that allows wired or wireless communication through a specific medium. The interface may include an application programming interface and / or method call or return. For example, in a software implementation, the interface may include passing data and / or memory references to a function initiated via a method call, wherein the function includes computer program code executed by one or more processors; in a hardware implementation, the interface may include wired interconnections between different chips, chipsets, or chip parts. In the accompanying drawings, the interface may be indicated by the boundaries of a processing block with inward arrows and / or outward arrows representing data transfer.

[0126] The terms "component" and "module" are used interchangeably to refer to a hardware structure with a specific function (e.g., in the form of mapping input data to output data), or a combination of general hardware and specific software (e.g., a specific computer program code executed on one or more general-purpose processors). A component or module can be implemented as a specifically packaged chipset, such as an application-specific integrated circuit (ASIC) or a programmed field programmable gate array (FPGA), and / or as a software object, class, class instance, script, code portion, etc., executed by a processor in use.

[0127] The term "machine learning model" as used herein refers to at least a hardware-implemented implementation of a machine learning model or function. Known models in the field of machine learning include logistic regression models, naive Bayes models, random forests, support vector machines, and artificial neural networks. Implementations of classifiers can be provided in one or more machine learning programming libraries (including but not limited to scikit-learn, TensorFlow, and PyTorch).

[0128] As used herein, the term "mapping" refers to a transformation or conversion of a first set of data values ​​to a second set of data values. The two sets of data values ​​may be arrays of different sizes, wherein the dimension of the output array is lower than the dimension of the input array. The input array and the output array may have a common data type or different data types. In some examples, the mapping is a one-way mapping to a scalar value.

[0129] The term "neural network architecture" refers to a collection of one or more artificial neural networks configured to perform a specific data processing task. For example, a "neural network architecture" may include a specific arrangement of one or more neural network layers of one or more neural network types. Neural network types include convolutional neural networks, recursive neural networks, and feedforward neural networks. Convolutional neural networks involve the application of one or more convolution operations. Recursive neural networks involve internal states that are updated during a series of inputs. Therefore, recursive neural networks are considered to include a form of recursive or feedback connections, whereby the state of the recursive neural network at a previous time or iteration (e.g., t-1) is used to update the state of the recursive neural network at a given time or iteration (e.g., t). Feedforward neural networks involve transformation operations without feedback, for example, applying operations in a unidirectional sequence from input to output. Feedforward neural networks include ordinary "neural networks" and "fully connected" neural networks. Those skilled in the art will understand that "multilayer perceptron" is a term used to describe a fully connected layer and is a special case of a feedforward neural network.

[0130] The term "deep" neural network is used to indicate that the neural network includes multiple neural network layers connected in series (it should be noted that this "deep" term is used with both feedforward neural networks and recursive neural networks). Certain examples described herein utilize recursive and fully connected neural networks.

[0131] A "neural network layer" generally defined in machine learning programming tools and libraries can be considered as an operation that maps input data to output data. A "neural network layer" can apply one or more parameters such as weights to map input data to output data. One or more bias terms can also be applied. The weights and biases of a neural network layer can be applied using one or more multidimensional arrays or matrices. Generally, a neural network layer has multiple parameters, the values ​​of which affect how the layer maps input data to output data. These parameters can be trained in a supervised manner by optimizing an objective function. This generally involves minimizing a loss function. Certain parameters can also be pre-trained or fixed in another way. Fixed parameters can be considered as configuration data that controls the operation of a neural network layer. A neural network layer or architecture can include a mixture of fixed parameters and learnable parameters. A recursive neural network layer can apply a series of operations to update a recursive state and transform input data. The update of the recursive state and the transformation of the input data can involve the transformation of one or more of the previous recursive state and the input data. A recursive neural network layer can be trained by unfolding a modeled recursive unit, as can be applied in a machine learning programming tool and library. Although a recursive neural network can be viewed as comprising several (sub) layers to apply different gating operations, most machine learning programming tools and libraries refer to the application of a recursive neural network as a whole as a "neural network layer", and this convention will be followed here. Finally, the feedforward neural network layer can apply one or more of a set of weights and biases to the input data to generate output data. This operation can be represented as a matrix operation (for example, where a bias term can be included by appending a value of 1 to the input data). Alternatively, the bias can be applied by a separate addition operation. As discussed above, according to the machine learning library, the term "tensor" is used to refer to an array that may have multiple dimensions, for example, a tensor may include a vector, a matrix, or a higher dimensional data structure. In a preferred example, the tensor described may include a vector having a predetermined number of elements.

[0132] In order to model complex non-linear functions, the neural network layers described above may be followed by a non-linear activation function. Common activation functions include sigmoid function, tanh function and rectified linear unit (RELU). Many other activation functions exist and can be applied. The activation function can be selected based on testing and preference. The activation function can be omitted in some cases and / or form part of the internal structure of the neural network layer.

[0133] The example neural network architectures described herein can be configured via training. In some cases, a method called back propagation can be used to train "learnable" or "trainable" parameters. During back propagation, the neural network layers that make up each neural network architecture are initialized (e.g., using randomized weights) and then used to make predictions (e.g., so-called "forward" passes) using a set of input data from a training set. The predictions are used to evaluate the loss function. For example, the "ground truth" output can be compared with the predicted output, and the difference can form part of the loss function. In some examples, the loss function can be based on the absolute difference between the predicted scalar value and the binary ground truth label. The training set can include a set of transactions. If a gradient descent method is used, the loss function is used to determine the gradient of the loss function relative to the parameters of the neural network architecture, where the gradient is then used to back propagate updates to the parameter values ​​of the neural network architecture. Typically, updates are propagated based on the derivatives of the weights of the neural network layer. For example, the gradient of the loss function relative to the weights of the neural network layer can be determined and used to determine the update of the weights that minimizes the loss function. In this case, optimization techniques such as gradient descent, stochastic gradient descent, Adam, etc. can be used to adjust the weights. The chain rule and automatic differentiation can be applied to efficiently compute the gradient of the loss function, working its way through the neural network layers. BRIEF DESCRIPTION OF THE DRAWINGS

[0134] Certain embodiments of the present invention will now be described with reference to the accompanying drawings, in which:

[0135] Figures 1A to 1C are schematic diagrams illustrating different example electronic infrastructures for transaction processing;

[0136] Figure 2A and Figure 2B is a schematic diagram illustrating different examples of data storage systems used by a machine learning transaction processing system;

[0137] Figure 3A and Figure 3B are schematic diagrams showing different examples of transaction data.

[0138] Figure 4 is a schematic diagram illustrating example components of a machine learning transaction processing system;

[0139] Figure 5A and Figure 5B is a sequence diagram illustrating a set of example processes performed on transaction data by different computing entities;

[0140] Figure 6 is a schematic diagram illustrating a machine learning system according to an embodiment of the present invention; and

[0141] Figure 7 It is shown in Figure 6 Schematic diagram of the operation of the classification history module used in the machine learning system. DETAILED DESCRIPTION

[0142] Certain exemplary embodiments are described herein involving machine learning systems for use in transaction processing. In certain embodiments, a machine learning system is applied in a real-time, high-volume transaction processing pipeline to provide an indication of whether a transaction or entity matches a previously observed and / or predicted activity or action pattern, such as an indication of whether the transaction or entity is "normal" or "abnormal". The term "behavioral" as used herein refers to such a pattern of activity or action. The indication may include a scalar value normalized within a predefined range (e.g., 0 to 1), which may then be used to prevent fraud and other abuses of the payment system. The machine learning system may apply a machine learning model that is updated as more transaction data is obtained, for example, a machine learning model that is continuously trained based on new data to reduce false positives and maintain the accuracy of the output metrics. This example may be particularly useful for fraud prevention in situations where the actual presence of a payment card cannot be determined (e.g., online transactions known as "card-not-present"), or for commercial transactions where high-value transactions may be routine and it may be difficult to classify behavioral patterns as "unexpected". Therefore, in situations where transactions are primarily "online", i.e., conducted digitally over one or more public communication networks, this example facilitates the processing of these transactions.

[0143] Certain embodiments described herein enable machine learning models to be tailored to behavioral patterns specific to certain pairs of entities (such as account holders) and categories (such as merchants, transaction amounts, time of day, etc.). For example, a machine learning model can model behavioral patterns specific to entity-category pairs. The machine learning system described herein can provide dynamically updated machine learning models despite large transaction flows and / or despite the need to separate different data sources.

[0144] As previously outlined, embodiments of the present invention can be applied to a variety of digital transactions, including but not limited to card payments, so-called "wire" transfers, peer-to-peer payments, Bank's Automated Clearing System (BACS) payments, and Automated Clearing House (ACH) payments. The output of the machine learning system can be used to prevent a variety of fraud and crime, such as card fraud, application fraud, payment fraud, merchant fraud, gaming fraud, and money laundering.

[0145] The present exemplary machine learning system (eg, configured and / or trained as outlined below) is configured to detect novelty in entity-category interactions.

[0146] The following describes non-limiting exemplary implementations of machine learning systems according to embodiments of the present invention. Figures 1A to 5B Provides context for machine learning systems. Figure 6 and Figure 7 Shown is a machine learning system in the form of a specific neural network architecture.

[0147] Example Transaction Processing System

[0148] Figures 1A to 1C A set of example transaction processing systems 100, 102, 104 are shown. These example transaction processing systems are described to provide context for the inventions discussed herein, but should not be considered limiting; the configuration of any one implementation may differ based on the specific requirements of that implementation. However, the example transaction processing systems described enable one skilled in the art to identify certain high-level technical features relevant to the following description. The three example transaction processing systems 100, 102, 104 illustrate different areas where variation may occur.

[0149] Figures 1A to 1C A group of client devices 110 configured to initiate a transaction is shown. In this example, the group of client devices 110 includes a smart phone 110-A, a computer 110-B, a point of sale (POS) system 110-C, and a portable merchant device 110-D. These client devices 110 provide a non-exhaustive example group. Generally, any electronic device or device group can be used to conduct a transaction. In one case, the transaction includes a purchase or payment. For example, the purchase or payment can be an online or mobile purchase or payment made by means of a smart phone 110-A or a computer 110-B, or can be a purchase or payment made at a merchant's location (such as via a POS system 110-C or a portable merchant device 110-D). The purchase or payment can be for goods and / or services.

[0150] exist Figures 1A to 1C In the embodiment, client device 110 is communicatively coupled to one or more computer networks 120. Client device 110 may be communicatively coupled in a variety of ways, including through one or more wired networks including telecommunications networks and / or wireless networks. In a preferred example, all communications across the one or more computer networks are secure, for example using the Transport Layer Security (TLS) protocol. Figure 1A, two computer networks 120-A and 120-B are shown. These may be separate networks or different parts of a common network. The first computer network 120-A communicatively couples the client device 110 to a merchant server 130. The merchant server 130 may perform computer processing to implement the processing flow of the transaction. For example, the merchant server 130 may be a back-end server that processes transaction requests received from a POS system 110-C or a portable merchant device 110-D, or may be used by an online merchant to implement a website where purchases can be made. It will be understood that Figures 1A to 1C The examples are necessarily simplifications of actual architectures; for example, there may be several interacting server devices implementing an online merchant, including a separate server device for serving Hypertext Markup Language (HTML) pages detailing products and / or services and for handling payment processing.

[0151] exist Figure 1A In the example, the merchant server 130 is communicatively coupled to another set of backend server devices to process transactions. Figure 1A In the example embodiment, the merchant server 130 is communicatively coupled to the payment processor server 140 via the second network 120-B. The payment processor server 140 is communicatively coupled to a first data storage device 142 storing transaction data 146 and a second data storage device 144 storing auxiliary data 148. The transaction data 146 may include batch transaction data related to different transactions conducted within a certain period of time. The auxiliary data 148 may include data associated with the transaction, such as a record storing merchant and / or end user data. Figure 1A, the payment processor server 140 is communicatively coupled to the machine learning server 150 via the second network 120-B. The machine learning server 150 implements a machine learning system 160 for processing transaction data. The machine learning system 160 is arranged to receive input data 162 and map it to output data 164 used by the payment processor server 140 to process a specific transaction (such as a transaction generated from the client device 110). In one case, the machine learning system 160 receives at least transaction data associated with a specific transaction and provides an alert or digital output used by the payment processor server 140 to determine whether the transaction is authorized (i.e., approved) or rejected. Therefore, the output of the machine learning system 160 may include a label, alert or other indication of fraud, or general malicious or abnormal activity. The output may include a probability indication, such as a score or probability. In one case, the output data 164 may include a scalar numerical value. The input data 162 may also include data derived from one or more of the transaction data 146 and the auxiliary data 148. In one case, the output data 164 indicates a level of deviation from a specific expected behavior pattern based on past observations or measurements. This may indicate fraudulent or criminal behavior, for example, as this is often significantly different from observed behavioral patterns, especially at scale. The output data 164 may form behavioral measures. Expected behavioral patterns may be defined explicitly or implicitly based on observed interactions between different entities in the transaction processing flow, such as end users or customers, merchants (including point of sale and back-end locations or entities that may be different from these), and banks.

[0152] The machine learning system 160 can be implemented as part of a transaction processing pipeline. Figure 5A and Figure 5B1 to describe an example transaction processing pipeline. The transaction processing pipeline may include electronic communications between a client device 110, a merchant server 130, a payment processor server 140, and a machine learning server 150. Other server devices may also be involved, such as a banking server that provides authorization from an issuing bank. In some cases, the client device 110 may communicate directly with the payment processor server 140. In use, the transaction processing pipeline is typically required to be completed within one hundred milliseconds or two hundred milliseconds. Typically, sub-second processing times can be considered real-time (e.g., humans typically perceive events over a 400ms time span). In addition, 100ms to 200ms may be the expected maximum delay for the full round-trip time of transaction processing; within this time span, the time allocated to the machine learning system 160 may be a small fraction of this total amount, such as 10ms (i.e., less than 5% to 10% of the target processing time), because most of the time can be reserved for other operations in the transaction processing flow. This imposes technical limitations on the implementation of the machine learning system 160. In addition, in real-world implementations, the average processing volume may be on the order of 1000 to 2000 per second. This means that most “off-the-shelf” machine learning systems are not suitable for implementing machine learning system 160. It also means that most machine learning methods described in academic papers cannot be implemented in the above transaction processing pipeline without non-obvious adjustments.

[0153] In addition, existing machine learning systems do not extract entity-category interaction novelty. Figure 6 and Figure 7 As described, a machine learning system according to an embodiment of the present invention can be used to provide a variety of technical benefits.

[0154] Figure 1B Shows Figure 1A A variation 102 of the example transaction processing system 100 is provided. In this variation 102, the machine learning system 160 is implemented within a payment processor computer infrastructure, such as executed by a payment processor server 140 and / or on a locally coupled server within the same local network as the payment processor server 140. Figure 1B Variant 102 of may be preferred for larger payment processors because it allows for faster response times, better control, and improved security. However, functionally, the transaction processing pipeline may be similar to Figure 1A For example, in Figure 1A In the example of , the machine learning system 160 can be initiated by a secure external application programming interface (API) call (such as a representational state transfer (REST) ​​API call using hypertext transfer protocol secure (HTTPS)), and in Figure 1BIn the example, the machine learning system 160 can be initiated by an internal API call, but the public API can handle both requests (e.g., a REST HTTPS API can provide an external wrapper for the internal API).

[0155] Figure 1C Shows Figure 1A Another variation 104 of the example transaction processing system 100. In this variation 104, the machine learning system 160 is communicatively coupled to a local data storage device 170. For example, the data storage device 170 may be on the same local network as the machine learning server 150, or may include a local storage network accessible to the machine learning server 150. In this case, there are multiple local data storage devices 170-A to 170-N, each of which stores partitioned ancillary data 172. The partitioned ancillary data 172 may include parameters for one or more machine learning models. In one case, the ancillary data 172 may include the state of the machine learning model, where the state may relate to a specific entity, such as a user or a merchant. It may be necessary to apply partitioning of the ancillary data 172 to meet security requirements set by a third party, such as a payment processor, one or more banks, and / or one or more merchants. In use, the machine learning system 160 accesses the ancillary data 172-A to 172-N via multiple local data storage devices 170-A to 170-N based on the input data 162. For example, input data 162 may be received by way of an API request from a particular source and / or may include data identifying a particular partition to be used to process the API request. Figure 2A and Figure 2B More details on different storage systems that can be applied to meet security requirements are listed in.

[0156] Example data storage configuration

[0157] Figure 2A and Figure 2B Two example data storage configurations 200 and 202 are shown that may be used by an example machine learning system 210 to process transaction data. Figure 2A and Figure 2B The examples are two non-limiting examples showing different options that can be used for implementation, and a particular configuration may be selected based on individual circumstances. The machine learning system 210 may include Figures 1A to 1C An implementation of the machine learning system 160 described in the previous example of . Figure 2A and Figure 2BThe example allows processing of transaction data protected using heterogeneous cryptographic parameters, for example, allowing the machine learning system 210 to securely process transaction data of heterogeneous entities. It will be appreciated that if the machine learning system 160 is implemented for a single secure transaction and auxiliary data set, such as within an internal transaction processing system or as a hosted system for use by a single payment processor, then it may not be necessary to use Figure 2A and Figure 2B Configuration.

[0158] Figure 2A The machine learning system 210 is shown communicatively coupled to a data bus 220. The data bus 220 may include an internal data bus of the machine learning server 150, or may form part of a storage area network. The data bus 220 communicatively couples the machine learning system 210 to a plurality of data storage devices 230, 231, 232. The data storage devices 230, 231, 232 may include any known data storage devices, such as magnetic hard disks and solid-state devices. Although the data storage devices 230, 231, 232 may be stored in a plurality of storage devices, the data storage devices 230, 231, 232 may be stored in a plurality of storage devices. Figure 2A In the diagram, the plurality of devices are shown as different devices, but they may alternatively form different physical storage areas or storage portions in a common data storage device. Figure 2A In the example, multiple data storage devices 230, 231, 232 store entity transaction data 240, classification history transaction data 241 (e.g., a table of state data of stored entity-class pairs, as outlined in more detail later), and auxiliary data 242.

[0159] exist Figure 2A In the embodiment, the first group of data storage devices 230 stores entity transaction data 240; the second group of data storage devices 231 stores classified historical transaction data 241; and the third group of data storage devices 232 stores auxiliary data 242.

[0160] Auxiliary data 242 may include model parameters of a set of machine learning models (such as training parameters of a neural network architecture and / or configuration parameters of a random forest model) and one or more of the state data of these models. In one case, different sets of entity transaction data 240-A to 240-N, classified historical transaction data 241-A to 241-N, and auxiliary data 242-A to 242-N are associated with different entities that securely and collectively use the services provided by the machine learning system 210. For example, these data may represent data of different banks, which need to be kept separate as part of the conditions for providing machine learning services to these entities.

[0161] Figure 2BAnother way in which different sets of entity transaction data 240-A to 240-N, categorized historical transaction data 241-A to 241-N, and auxiliary data 242-A to 242-N may be stored is shown. Figure 2B In the example, the machine learning system 210 is communicatively coupled to at least one data storage device 260 via a data transmission channel 250. The data transmission channel 250 may include a local storage bus, a local storage area network, and / or a remote secure storage coupling (e.g., such as overlaid on an unsecured network such as the Internet). Figure 2B In the embodiment of the present invention, a physical data storage device 260 is used to provide a secure logical storage layer 270. The secure logical storage layer 270 can be a virtualized system that appears to the machine learning system 210 as a separate physical storage device, but is actually independently implemented on the at least one data storage device 260. The logical storage layer 270 can provide separate encrypted partitions 280 for data related to an entity group (e.g., data related to different issuing banks, etc.), and different entity transaction data 240-A to 240-N, classified historical transaction data 241-A to 241-N, and auxiliary data 242-A to 242-N can be stored in corresponding partitions 280-A to 280-N. In some cases, when receiving a transaction based on the Figures 1A to 1C Entities are created dynamically as data stored by one or more of the server systems is processed.

[0162] Sample transaction data

[0163] Figure 3A and Figure 3B An example of transaction data that may be processed by a machine learning system such as 160 or 210 is shown. Figure 3A 300, where each record has a timestamp and includes a plurality of transaction fields. In some cases, the transaction data can be grouped and / or filtered based on the timestamp. For example, Figure 3A The partitioning of transaction data into current transaction data 310 associated with the current transaction and "older" or historical transaction data 320 within a predefined time range of the current transaction is shown. The time range can be set as a hyperparameter of any machine learning system. Alternatively, the "older" or historical transaction data 320 can be set to a certain number of transactions. A hybrid of the two approaches is also possible.

[0164] Figure 3B 3 shows how transaction data 330 for a particular transaction may be stored in digital form for processing by one or more machine learning models. Figure 3BIn the transaction data, the transaction data has at least the fields: transaction amount, timestamp (e.g., as a Unix epoch), transaction type (e.g., card payment or direct debit), product description or identifier (i.e., related to the item being purchased), merchant identifier, issuing bank identifier, a set of characters (e.g., Unicode characters within a field of predefined character length), country identifier, etc. It should be noted that a wide variety of data types and formats can be received and preprocessed into appropriate digital representations. In some cases, raw transaction data (such as data generated by a client device and sent to the merchant server 130) is preprocessed to convert alphanumeric data types to numeric data types for application of one or more machine learning models. Other fields present in the transaction data may include, but are not limited to, an account number (e.g., a credit card number), the location where the transaction occurred, and the manner in which the transaction was performed (e.g., in person, over the phone, on a website).

[0165] As outlined in further detail below, Figure 6 and Figure 7 The machine learning system 600 is intended to identify the novelty of interactions between an entity (e.g., a cardholder) and one or more categories (e.g., a merchant, a merchant type, a transaction amount, a time of day, a day of the week, etc.). Fields in the transaction data can be used directly to identify the relevant category or categories. Additionally or alternatively, a category or categories associated with the transaction can be inferred or derived from the transaction data. It will be appreciated that such derived categories can be obtained in a variety of ways. As non-limiting examples, this can include: simple preprocessing, such as binning of numerical features; preprocessing that combines multiple categories; or a machine learning model that learns to compose useful categories and is trained in conjunction with the main machine learning system 600.

[0166] Example Machine Learning System

[0167] Figure 4 An example 400 of a machine learning system 402 that can be used to process transaction data is shown. The machine learning system 402 can implement one or more of the machine learning systems 160 and 210. The machine learning system 402 receives input data 410. The form of the input data 410 can depend on which machine learning model the machine learning system 402 is applying. In the case where the machine learning system 402 is configured to perform fraud or anomaly detection related to transactions (e.g., ongoing transactions as described above), the input data 410 can include transaction data, such as 330 (i.e., data that forms part of a data packet of a transaction), and transaction data from an entity (such as, Figure 3A300) and / or from classified historical data (as further detailed below) and / or from auxiliary data (such as, Figures 1A to 1C 148 or Figure 2A and Figure 2B 242 in). Auxiliary data may include secondary data linked to one or more entities identified in the primary data associated with the transaction. For example, if the transaction data of an ongoing transaction identifies a user, a merchant, and one or more banks associated with the transaction (such as the user's issuing bank and the merchant's bank) such as via a unique identifier present in the transaction data, the auxiliary data may include data related to these transaction entities. Auxiliary data can be used to enrich the information available to the neural network layer. Auxiliary data may also include data derived from records of activities (such as interaction logs and / or authentication records). In one case, the auxiliary data is stored in one or more static data records and retrieved from these records based on the received transaction data. Additionally or alternatively, the auxiliary data may include machine learning model parameters retrieved based on the content of the transaction data. For example, a machine learning model may have parameters specific to one or more of a user, a merchant, and an issuing bank, and these parameters may be retrieved based on which of them is identified in the transaction data. For example, one or more of users, merchants, and issuing banks may have corresponding embeddings, which may include retrievable or mappable tensor representations of the entities. For example, each user or merchant may have a tensor representation (e.g., a floating point vector of size 128 to 1024) that may be retrieved from a database or other data store, or may be generated by an embedding layer, for example, based on a user or merchant index.

[0168] Input data 410 is received at input data interface 412. Input data interface 412 may include an API interface, such as an internal API interface or an external API interface as described above. Figures 1A to 1CThe payment processor server 140 shown issues a request to the interface, wherein the request payload contains transaction data. The API interface can be defined as being agnostic to the form of the transaction data or its source. The input data interface 412 is communicatively coupled to the machine learning model platform 414. In one case, the request made to the input data interface 412 triggers the execution of the machine learning model platform 414 using the transaction data supplied to the interface. The machine learning model platform 414 is configured as an execution environment for applying one or more machine learning models to the input data 410. In one case, the machine learning model platform 414 is arranged as an execution wrapper for multiple different selectable machine learning models. For example, a model definition language (e.g., similar to or using a markup language such as an extended markup language-XML) can be used to define the machine learning model. The model definition language can include (among others, independently or in combination) SQL, TensorFlow, Caffe, Thinc, and PyTorch. In one case, the model definition language includes a computer program code that can be executed to implement one or more of the training and reasoning of the defined machine learning model. For example, machine learning models may include artificial neural network architectures, ensemble models, regression models, decision trees such as random forests, graphical models, and Bayesian networks, among others. Figure 6 An example machine learning model based on an artificial neural network is described. The machine learning model platform 414 can define common (ie, shared) input definitions and output definitions, so as to apply different machine learning models in a common (ie, shared) manner.

[0169] In this example, the machine learning model platform 414 is configured to provide at least a single scalar output 416. This may be normalised within a predefined range such as 0 to 1. When normalised, the scalar output 416 may be viewed as a probability that a transaction associated with the input data 410 is fraudulent or abnormal. In this case, a value of "0" may represent a transaction that matches a normal activity pattern for one or more of a user, a merchant and an issuing bank, while a value of "1" may indicate that the transaction is fraudulent or abnormal, i.e., does not match an expected activity pattern (although those skilled in the art will appreciate that the normalised range may be different, such as inverted or within different bounds, and have the same functional effect). It should be noted that although the range of values ​​may be limited to 0 to 1, the output values ​​may not be evenly distributed within the range, for example, a value of "0.2" may be a common output for a "normal" event, and a value of "0.8" may be viewed as exceeding a threshold for a typical "abnormal" or fraudulent event. Thus, the machine learning model implemented by the machine learning platform 414 can implement a mapping form between high-dimensional input data (e.g., transaction data and any retrieval auxiliary data) and a single value output. In one case, for example, the machine learning platform 414 can be configured to receive input data for the machine learning model in a digital format, wherein each defined machine learning model is configured to map input data defined in the same manner. The exact machine learning model applied by the machine learning model platform 414 and the parameters of the model can be determined based on the configuration data. The configuration data can be included in the input data 410, and / or identified using the input data 410, and / or can be set based on one or more configuration files parsed by the machine learning platform 414.

[0170] In some cases, the machine learning model platform 414 may provide additional outputs based on the context. In some implementations, the machine learning model platform 414 may be configured to return a “reason code” that captures a human-friendly description of the output of the machine learning model based on suspicious input attributes. For example, the machine learning model platform 414 may indicate which of one or more input elements or units in the input representation affects the model output, such as a combination of a “volume” channel above a learned threshold and a set of “merchant” elements or units (such as embeddings or indexes) outside a given cluster that affects the model output. In the case where the machine learning model platform 414 implements a decision tree, these additional outputs may include aggregate feature importances for paths through the decision tree or tree-based collections. For a neural network architecture, this may include layer output activations and / or layer filters with positive activations.

[0171] exist Figure 4In some implementations, the scalar output 416 may be directly passed to the output data interface 420 without post-processing. In the latter case, the scalar output 416 may be packaged as a response to the original request of the input data interface 412. In both cases, the output data 422 derived from the scalar output 416 is provided as an output of the machine learning system 402. The output data 422 is returned to allow final processing of the transaction data. For example, the output data 422 may be returned to the payment processor server 140 and used as the basis for a decision to approve or reject the transaction. Depending on the implementation requirements, in one case, the alert system 418 may process the scalar output 416 to return a binary value indicating whether the transaction should be approved or rejected (e.g., "1" equals rejection). In some cases, the decision can be made by applying a threshold to the scalar output 416. The threshold may be context dependent. In some cases, the alarm system 418 and / or the output data interface 420 may also receive additional inputs, such as descriptive data (e.g., the "reason code" discussed above) and / or raw input data. The output data interface 420 may generate an output data packet for output data 422 that combines these inputs with the scalar output 416 (e.g., at least for logging and / or later viewing). Similarly, the alarms generated by the alarm system 418 may include and / or be additionally based on the additional inputs described above, such as in addition to the scalar output 416.

[0172] The machine learning system 402 can be used in an "online" mode to process a large number of transactions within a narrowly defined time frame. For example, under normal processing conditions, the machine learning system 402 can process a request within 7ms to 12ms and is capable of managing 1000 to 2000 requests per second (these are intermediate constraints from real-world operating conditions). However, the machine learning system 402 can also be used in an "offline" mode, for example by providing selected historical transactions to the input data interface 412. In offline mode, the input data can be passed to the input data interface in batches (i.e., groups). The machine learning system 402 can also be capable of implementing a machine learning model that provides a scalar output for an entity as well as a transaction or in lieu of a transaction. For example, the machine learning system 402 can receive a request associated with an identified user (e.g., a card or payment account holder) or an identified merchant, and is arranged to provide a scalar output 416 that indicates the likelihood that the user or merchant is fraudulent, malicious, or abnormal (i.e., a general threat or risk). For example, this can form part of a continuous or periodic monitoring process, or a one-off request (e.g., as part of an application of a service). Providing a scalar output for a particular entity may be based on a set of transaction data up to and including the last approved transaction in a sequence of transaction data (e.g., similar to Figure 3A Transaction data for the entity shown in ).

[0173] Example transaction process

[0174] Figure 5A and Figure 5B Two possible transaction processing flows 500 and 550 are shown respectively. These processing flows can occur at Figures 1A to 1C The process flows 500 and 550 are provided as an example of a context in which machine learning transaction processing systems may be applied, however, not all transaction processing flows will necessarily follow Figure 5A and Figure 5B, and the processing flows may vary between implementations, systems, and over time. Example transaction processing flows 500 and 550 reflect two possible scenarios: a first scenario represented by transaction processing flow 500, in which the transaction is approved; and a second scenario represented by transaction processing flow 550, in which the transaction is declined. Each transaction processing flow 500, 550 involves the same set of five interacting systems and devices: a POS or user device 502, a merchant system 504, a payment processor (PP) system 506, a machine learning (ML) system 508, and an issuing bank system 510. The POS or user device 502 may include one of the client devices 110, the merchant system 504 may include a merchant server 130, the payment processor system 506 may include a payment processor server 140, and the machine learning system 508 may include an implementation of the machine learning system 160, 210, and / or 402. The issuing bank system 510 may include one or more server devices that implement transaction functions on behalf of the issuing bank. The five interactive systems and devices 502 to 510 may be communicatively coupled via one or more internal communication channels or external communication channels (such as network 120). In some cases, some of these systems may be combined, such as an issuing bank may also act as a payment processor, and thus systems 506 and 510 may be implemented with a common system. In other cases, a similar processing flow may be performed specifically for merchants (e.g., without involving a payment processor or issuing bank). In this case, machine learning system 508 may communicate directly with merchant system 504. In these variations, the general functional transaction processing flow may remain similar to the flow described below.

[0175] exist Figure 5A and Figure 5BThe transaction processing flow in both includes a plurality of common (i.e., shared) processes 512 to 528. At block 512, a POS or user device 502 initiates a transaction. For a POS device, this may include a cashier using a front-end device to attempt to make an electronic payment; for a user device 502, this may include a user using a credit or debit card or an online payment account to make an online purchase (e.g., clicking "Done" in an online shopping basket). At block 514, the payment details are received by the merchant system 504 as electronic data. At block 516, the transaction is processed by the merchant system 504, and a request for authorization of payment is made to the payment processor system 506. At block 518, the payment processor system 506 receives the request from the merchant system 504. The request may be made through a proprietary communication channel or as a secure request on a public network (e.g., an HTTPS request on the Internet). The payment processor system 506 then requests a score or probability for processing the transaction from the machine learning system 508. Block 518 may also include retrieving auxiliary data to combine with the transaction data sent to the machine learning system 508 as part of the request. In other cases, the machine learning system 508 may access a data storage device storing auxiliary data (e.g., similar to Figure 2A and Figure 2B ) and thus retrieve that data as part of an internal operation (e.g., based on an identifier provided within the transaction data and / or as defined as part of an implemented machine learning model).

[0176] Block 520 illustrates model initialization operations that occur prior to any request from the payment processor system 506. For example, the model initialization operations may include loading a defined machine learning model and instantiating parameters of the defined machine learning model. At block 522, the machine learning system 508 receives a request from the payment processor system 506 (e.g., via a server such as Figure 4 412 in the data input interface). At block 522, the machine learning system 508 may perform any defined pre-processing before applying the machine learning model initialized at block 520. For example, where the transaction data still retains character data (such as a merchant identified by a string or character transaction description), this may be converted into suitable structured digital data (e.g., by converting string classification data into identifiers via a lookup operation or other mapping, and / or by mapping characters or character groups into vector embeddings). Then, at block 524, the machine learning system 506 applies the instantiated machine learning model, supplying the model with input data derived from the received request. This may include applying, for example, reference Figure 4The machine learning model platform 414 described above. At block 526, a scalar output is generated by the instantiated machine learning model. This can be processed at the machine learning system 508 to determine an "approval" or "rejection" binary decision, or, in the preferred case, returned to the payment processor system 506 as a response to the request made at block 518.

[0177] At block 528, the output of the machine learning system 508 is received by the payment processor system 506 and used to approve or deny the transaction. Figure 5A A process for approving a transaction based on the output of the machine learning system 508 is shown; Figure 5B The process of declining a transaction based on the output of the machine learning system 508 is shown. Figure 5A , at block 528, the transaction is approved. Then at block 530, a request is made to the issuing bank system 532. At block 534, the issuing bank system 532 approves or denies the request. For example, if the end user or cardholder has sufficient funds and approval to pay the transaction cost, the issuing bank system 532 can approve the request. In some cases, the issuing bank system 532 can apply a second level of security; however, this may not be necessary if the issuing bank relies on anomaly detection performed by the payment processor using the machine learning system 508. At block 536, the authorization from the issuing bank system 510 is returned to the payment processor system 506, which in turn sends a response to the merchant system 504 at block 538, and the merchant system 504 in turn responds to the POS or user device 502 at block 540. If the issuing bank system 510 approves the transaction at block 534, the transaction can be completed, and the affirmative response is returned to the POS or user device 502 via the merchant system 504. The end user may experience this as an "authorization" message on the screen of the POS or user device 502. The merchant system 504 may then complete the purchase (e.g., initiate internal processing to complete the purchase).

[0178] At a later point in time, one or more of the merchant system 504 and the machine learning system 508 may save data related to the transaction, for example, as part of the transaction data 146, 240, or 300 and / or the classification history data 241 (as discussed in further detail below). This is shown at dashed blocks 542 and 544. The transaction data and / or classification history data may be saved along with one or more of the outputs of the machine learning system 508 (e.g., scalar fraud or anomaly probability) and the final outcome of the transaction (e.g., whether the transaction was approved or rejected). The saved data may be stored for use as training data for a machine learning model implemented by the machine learning system 508 (e.g., as a basis for the training data shown in one or more of FIG. 8 and FIG. 10). The saved data may also be accessed as part of a future iteration of block 524, for example, may form part of future auxiliary data. In some cases, the final outcome or outcome of a transaction may be unknown at the time of the transaction. For example, a transaction may be simply marked as an anomaly via later review by an analyst and / or automated system or based on feedback from a user (e.g., when a user reports fraud or indicates that a payment card or account has been compromised since a certain date). In these cases, ground truth labels may be collected over time following the transaction itself for the purpose of training the machine learning system 508.

[0179] Now go to Figure 5B , in which case one or more of the machine learning system 508 and the payment processor system 506 deny the transaction based on the output of the machine learning system 508. For example, if the scalar output of the machine learning system 508 is above a retrieved threshold, the transaction can be denied. At block 552, the payment processor system 506 issues a response to the merchant system 504, which is received at block 554. At block 554, the merchant system 504 takes steps to prevent the transaction from being completed and returns an appropriate response to the POS or user device 502. The response is received at block 556, and the end user or customer can be informed, for example, via an on-screen "Denied" message that their payment has been denied. The end user or customer may be prompted to use a different payment method. Although in Figure 5B Not shown, but in some cases, the issuing bank system 510 can be notified that a transaction associated with a particular account holder has been declined. Figure 5B Part of the illustrated process causes the issuing bank system 510 to be informed, or may be informed as part of a regular (e.g., daily) update. Although the transaction may not become part of the transaction data 146, 240, or 300 (because it was not approved), it may still be at least recorded by the machine learning system 508, as indicated by block 544. For example, for Figure 5A, the transaction data can be saved along with the output of the machine learning system 508 (e.g., a scalar fraud or anomaly probability) and the final outcome of the transaction (e.g., transaction declined).

[0180] Machine learning system with classification history module

[0181] Some examples described herein (such as Figures 1A to 1C , Figure 2A and Figure 2B , Figure 4 as well as Figure 5A and Figure 5B The machine learning systems 160, 210, 402, and 508 in the example embodiment of the present invention can be implemented as a modular platform that allows different machine learning models and configurations to be used to provide the transaction processing described herein. The modular platform can allow different machine learning models and configurations to be used as the technology improves and / or based on the specific characteristics of the available data.

[0182] The machine learning system 600 according to an embodiment of the present invention is Figure 6 and Figure 7 , as described in further detail below.

[0183] As previously discussed, it should be noted that, although in the specific implementation described below, the state data is stored in a vector table, the state data can be easily constructed as an n-dimensional tensor and / or can be stored in some other data structure or format, for example, in a multi-dimensional array. Similarly, the various vectors described with respect to this implementation (e.g., input vectors, output vectors, etc.) can also be n-dimensional tensors and can be stored using any appropriate data structure.

[0184] The machine learning system 600 receives input data 601 and maps it to a scalar output 602. The general process follows the same framework as previously described. The machine learning system 600 includes a first processing stage (or "lower model") 603 and a second processing stage (or "upper model") 604.

[0185] The machine learning system 600 is applied to data associated with at least a proposed transaction to generate a scalar output 602 for the proposed transaction. The scalar output 602 indicates a likelihood that the proposed transaction exhibits a behavioral anomaly, e.g., the proposed transaction embodies an action or event pattern that is different from an expected or typical action or event pattern. In some cases, the scalar output 602 indicates a probability that the proposed transaction exhibits an anomaly in a sequence of actions, where the actions include at least a previous transaction for the entity and entity class pair, as outlined in more detail below. The scalar output 602 can be used to complete an approval decision for the proposed transaction, e.g., as described with reference to Figure 5A and Figure 5BAs described, it can be used to decide whether to approve or reject a proposed transaction.

[0186] Input data may include transaction time data and transaction characteristic data. Transaction time data may include data from, for example, Figure 3B or any other data format representing the date and / or time of the transaction. The date and / or time of the transaction may be set to the time when the transaction was initiated at the client computing device such as 110 or 502, or may be set to the time when the request was received at the machine learning system 600, for example, similar to Figure 5A and Figure 5B The time of the request received at block 522 in . The transaction time data may include time data for multiple transactions (such as the currently proposed transaction and a historical set of one or more prior transactions). The time data for the historical set of one or more prior transactions can be received with the request and / or retrieved from a storage device communicatively coupled to the machine learning system 600.

[0187] exist Figure 6 In an arrangement of, transaction time data is converted into relative time data for application of one or more neural network architectures. In particular, the transaction time data is converted into a set of time difference values, where the time difference value represents the time difference Δt between a currently proposed transaction and a previous transaction (typically the most recent previous transaction). For example, the time difference may include a normalized time difference in seconds, minutes, or hours. The time difference Δt may be calculated by subtracting the timestamp of the previous transaction (or multiple transactions, where multiple differences are being calculated and used) from the timestamp of the proposed transaction. The time difference values ​​may be normalized by dividing by a maximum predefined time difference and / or clipped at the maximum time difference value.

[0188] In inference mode, the machine learning system 600 detects a feature set from the input data 601 using an upper model 603 and a lower model 604 as outlined in more detail below. The output from the upper model 604 is a scalar value 602, which is used in determining whether to block a transaction (e.g., by comparing the scalar value 602 to a threshold).

[0189] like Figure 6 As shown, the machine learning system 600 includes a feedforward neural network based embedding layer within the lower model 603. In this particular embodiment, the embedding layer is a first multilayer perceptron 610, however it will be understood that this could alternatively be any other type of feedforward neural network, such as a transformer layer or a neural arithmetic logic unit.

[0190] The first multilayer perceptron 610 includes: a fully connected neural network architecture that includes multiple neural network layers (e.g., 1 to 10 layers) to preprocess the data of the proposed transaction from the input 601. Although a multilayer perceptron is described herein, in some implementations, preprocessing can be omitted (e.g., if the received transaction data in the input data 601 is already in a suitable format) and / or only a single layer of linear mapping can be provided. In some examples, the preprocessing can be viewed as a form of an "embedding" or "initial mapping" layer of the input transaction data. In some cases, one or more of the neural network layers of the first multilayer perceptron 610 can provide for learning to scale and / or normalize the received transaction data. In general, the fully connected neural network architecture of the first multilayer perceptron 610 represents a first learned feature preprocessing stage that converts the input data associated with the proposed transaction into a feature vector for further processing. In some cases, the fully connected neural network architecture can learn certain relationships between elements of the transaction feature data, such as certain correlations, and output an effective representation that takes these correlations into account. In one case, the input transaction data may include integers and / or floating point numbers, and the output 612 of the first multilayer perceptron 610 may include a vector of values ​​between 0 and 1. The number of elements or units (i.e., the output vector size) of the first multilayer perceptron 610 may be set as a configurable hyperparameter. In some cases, the number of elements or units may be between 32 and 2048.

[0191] The output 612 produced by the first multilayer perceptron 610 is split into two portions 612a, 612b which are provided respectively to a time decay unit 614 and a classification history module 616. However, it will be appreciated that while these are shown as being completely separable, arrangements are envisaged where there is at least some overlap in the portions of the output 612 that are fed to each of the time decay unit 614 and the classification history module 616.

[0192] It should be noted that the input transaction data of input 601 may include data from the proposed transaction (e.g., as received via one or more of the client device, POS device, merchant server device, and payment processor server device) as well as data associated with the proposed transaction but not included in the data packet associated with the proposed transaction. Figures 1A to 1C as well as Figure 2A and Figure 2B As illustrated, input 601 may also include auxiliary data (such as 148 and 242), wherein the auxiliary data is provided by machine learning system 600 (such as Figure 1C ) and / or by a payment processor server 140 (such as Figure 1A or Figure 1B) is retrieved. The exact content included in input data 601 may vary between implementations. This example relates to a general technical architecture for processing transaction data, rather than the exact form of that data. In general, because machine learning system 600 includes a set of neural network layers, parameters can be learned based on any input data configuration desired or based on available input data. This example relates to the engineering design of such a technical architecture to enable transaction processing at the speed and scale described herein.

[0193] exist Figure 6 In the example of FIG. 5 , the output of the first multilayer perceptron 610 is received by a time decay unit 614. The time decay unit 614 is configured to receive the output of the first multilayer perceptron 610 based on the previous state data h t-1 , the time difference Δt and a portion of the output 612a provided by the first multilayer perceptron 610 to generate the output data o t The time decay unit 614 may implement the techniques described in WO / 2022 / 008130 and WO / 2022 / 008131, each of which is incorporated herein by reference in its entirety.

[0194] Previous state data h t-1 is a vector of values ​​from previous transactions corresponding to the state of the system. Those skilled in the art will appreciate that, typically, the previous state data h t-1 is stored in memory and provides a history of the pattern of transactions that have occurred so far. State data is stored for each primary entity (eg cardholder) and thus the state data for a given primary entity provides information about the chain of previous transactions for that primary entity.

[0195] The degree of influence that the historical state data should have on the decision related to the proposed transaction may depend on the time difference Δt. If a long period of time has passed since the previous transaction, some of the state data may be less relevant in assessing whether the proposed transaction is abnormal or fraudulent. The time decay unit 614 applies a decay function to the previous state data h based on the time difference Δt. t-1 .

[0196] Once the previous state data h t-1 Having been decayed based on the time difference Δt, the time decay unit 614 performs mapping to generate output data o t The time decay unit 614 also adds the new state data h t Stored in memory for next transaction.

[0197] The mapping process performed by the time decay unit 614 may be based on machine learning. For example, the time decay unit 614 may use a neural network mapping (eg, one or more parameterized functions) to transform the previous state data h t-1 and the output 612a from the first multilayer perceptron 610 is mapped to a fixed size vector output of a predefined size. However, it will be appreciated that other approaches that do not require any such neural network or other machine learning techniques may be used.

[0198] Portion 612b of the output from the first multilayer perceptron 614 is input to the classification history module 616 and is specifically used by the update layer 619. Unlike the time decay unit 614, which operates with a single state data vector for each entity, the classification history module 616 builds a table (e.g., a lookup table) of multiple states, one for each secondary category that the primary entity has interacted with, as can be seen in reference to Figure 7 Better understood.

[0199] In a typical fraud application, the primary entity represents the payer or account holder, while the secondary category may represent the beneficiary of the funds, such as a merchant. However, it should be understood that the secondary category can be any classification field in the data. For example, it can be a numeric or date time field that has been divided into different categories, for example, "amount" can be divided into "low", "medium" and "high" categories; date and time can be divided into hours of the day or days of the week, etc. Categories can also be a combination of multiple categories (for example, a merchant identity is linked to a day of the week). Categories do not need to be ordered. In the following, in this specific example, for clarity, we will refer to the secondary classification field as "merchant". Note that all states will still be associated with the primary entity, so that state data is stored and retrieved for a specific entity-category pair. It will be understood that, therefore, there will typically be such a table for each primary entity.

[0200] In an exemplary software-based implementation, the table is a 2D tensor of shape (merchant_state_size, max_num_merchant_state), whose columns represent the various states of different merchants (of course it will be understood that different secondary categories can be used in other examples). It will be understood that "max_num_merchant_state" is the maximum number of merchants for which state data is stored (or equivalently, other category values, such as day of the week, transaction amount, or interval, etc.), i.e., the number of columns in the table. At the same time, "merchant_state_size" is the number of independent values ​​stored in each column, i.e., the number of rows in the table. As mentioned above, it should be understood that there will generally be such a state data table for each primary entity (i.e., for each account holder) so that the stored merchant (i.e., secondary category) data is specific to that primary entity.

[0201] The table in this example has a fixed size and therefore it has a limit on the number of merchant states that can be stored. As input, it receives the lookup table G (for this entity) from the previous time step t-1 t-1 and an update vector of size merchant_state_size. As output, it returns a vector containing the updated merchant state. In some embodiments, the vector may also include the decayed merchant state, for example by providing a vector of size 2*merchant_state_size that is the concatenation of the decayed merchant state and the updated merchant state (for the current merchant).

[0202] like Figure 7 As shown, for each transaction, the classification history module 616 performs decay and update logic similar to the standard time decay unit 614. The classification history module 616 first performs a decay and update operation on the table G. t-1 All stored states in apply exponential time decay, where the decay is based on the time difference Δt since the last transaction.

[0203] The decay function enables selective and regulated use of previous transaction data (ie, it can apply a certain degree of "forgetting") based on the time difference Δt between the proposed transaction and the previous transaction, where the previous transaction data is an aggregate function of the transaction feature vectors of multiple previous transactions.

[0204] The decay function can be applied in the form of a vectorized exponential time decay function, which is f(s) = [e [-s / w _ 1] , e [-s / w _ 2] ,……,e [-s / w_ d] ], i.e., as a series of parameterized time decay calculations, where [w_1, w_2 ... w_d] comprises a set of weights representing the "decay length" in seconds, and where d is the size of the recursive state vector (this can typically be equal to the length of the state data vector on which the decay function operates). In this case, Δt is passed to the function as s to output a vector of length d, e.g., Δt can be passed as a scalar floating point value representing the number of seconds that have passed between a previous event (e.g., a transaction) and a current event (e.g., a proposed transaction) for the same entity. The decay factors (i.e., weights) can be learned during the training process.

[0205] The decay weights may be fixed (e.g., manually configurable) parameters and / or may include trainable parameters. In the case of an exponential function, the decay length may include (or be trained to include) a mixture of different values ​​representing decays from minutes to weeks, so that both short-term and long-term behaviors are captured. The time decay function is applied to the state data table from the previous iteration using an element-wise multiplication (e.g., calculating the Hadamard product) between the time decay vector and each state data entry (the state data stored for each category, i.e., a column in the table). In this example, the state data includes a two-dimensional table of vectors, where the length of each vector is the same as the transaction feature vector output. This effectively controls how much of the state data from the previous iteration is remembered and how much is forgotten.

[0206] The table can be decayed using a range of time decay constants. For example, a short timescale decay will suppress memory contributions from old activity, while a long timescale decay will preserve memory contributions from old activity. This allows the network to compare new and old activity to determine novelty. Additionally, the state updates are a function of the input properties of the event. This means that some state elements may only be updated for certain types of events. This is useful in Figure 7 The grouping of different rows in the table is shown graphically in FIG. 1 , where the top three rows are retained for relatively long time periods, the middle three rows are retained for medium time periods, and the bottom three rows are retained for relatively short time periods. However, it will be understood that this is merely an example, and different time periods may be appropriately applied to each portion of the state data.

[0207] The network may learn that it has only seen certain types of activity with a given merchant before (e.g., low-value transactions), and therefore that the current event is also novel, even if that merchant has been novel before. For example, it may learn to ignore the presence of past low-value transactions with that merchant when risk scoring current high-value activity. The actual attenuation applied may be learned or may be predetermined (and may be user-defined, such as during initial setup or optimization of the system). In either case, the machine learning system may learn which attenuation weights should be applied to which combinations of behavioral features.

[0208] While in this exemplary embodiment, the entire table for a given entity is decayed, other embodiments are envisioned in which only the currently selected columns are decayed. To accomplish this, a timestamp may be stored for each entity-class pair, and the time difference Δt is taken as the time between the current transaction and the time when the data for the most recent instance of the entity-class pair was stored in the table.

[0209] After the decay step, the classification history module 616 extracts the merchant status column that matches the current merchantId (or a zero vector if it is a new merchant as outlined below). The classification history module 616 queries the lookup table using the current merchantId to see if the table contains status data for the merchant (i.e., does the column exist). If so, the status data stored for the merchantId is retrieved from the table. Conversely, if it does not exist in the table, a new "default" status (e.g., a zero vector) can be added to the table.

[0210] The output portion 612b from the multilayer perceptron 610 (which is again derived from the input vector x as previously outlined) is then used by the update layer 619 t derives) to update the state data (appropriately retrieved or new) and insert it back into the table. Although different approaches can be taken for the update step (i.e., for the step performed by the update layer 619), in one implementation, the decayed state data vector of entity-class pairs and the input vector from the first multilayer perceptron 610 (i.e., the output portion 612b) are added together using element-wise addition. This produces the output vector y t .

[0211] The table is managed as a stack - updated columns are inserted at the front of the table, and the least recently updated columns are at the back of the table. Due to the size limit of the table, if the table is full, new merchant states will be added by discarding the state of the merchant that was least recently seen. Figure 7 As can be seen in , the updated state data for the transaction is inserted at the front of the table, and the "gap" left at the back (as shown by the dotted line) is closed.

[0212] The output of the time decay unit 614 and the classification history module 616 is t ,y t Received by the upper model 604, and specifically by the second feedforward neural network output layer. In this particular embodiment, the output layer is a second multilayer perceptron 620, however it will be appreciated that this could alternatively be any other type of feedforward neural network, such as a transformer layer or a neural arithmetic logic unit. In this particular embodiment, the input data 601 is also fed to the second multilayer perceptron 620. In this example, the output of the time decay unit 614 and the classification history module 616 is t ,y t is passed directly to the second multilayer perceptron 620. However, other embodiments (not shown) are envisioned in which this passing is done indirectly via one or more additional intermediate neural network layers.

[0213] The second multilayer perceptron 620 is used to generate the scalar output 602. The second multilayer perceptron 620 includes a fully connected neural network architecture, which in turn includes a plurality of neural network layers for receiving the output of the time decay unit 614 and the classification history module 616. t ,y t and input data 601, and output those t ,y t to a scalar value 602. This may include a series of dimensionality reduction layers. The final activation function in the plurality of neural network layers may include a sigmoid activation function for mapping the output to a range of 0 to 1. The second multilayer perceptron 620 may be trained to extract correlations between features output by an attention mechanism (e.g., which may use multiple attention heads in a manner known per se in the art), and apply one or more nonlinear functions to ultimately output a scalar value 602.

[0214] Scalar value 602 can then be used by another part of the transaction processing pipeline (not shown) in deciding whether the transaction should be allowed to proceed normally or whether the transaction should be stopped and marked as fraudulent or abnormal. For example, the system can compare scalar value 602 to a suitable threshold value so that a score exceeding the threshold value is marked as abnormal.

[0215] In a preferred implementation, the state data is entity-dependent, i.e., specific to a particular user, account holder, or merchant account. In this way, the appropriate entity can be identified as part of the transaction data preprocessing, and the machine learning system 600 can be configured for that entity. In one instance, the machine learning system 600 can apply the same parameters to the neural network architecture for each entity, but can store the state data separately, and can retrieve only the historical transaction data and / or auxiliary data associated with (e.g., indexed by) that entity. Thus, the machine learning system 600 can include an entity state store, e.g., as described with reference to Figure 2A and Figure 2B As described, the data of different entities can be effectively divided. In other cases, the parameters of the decay function can be shared across multiple entities. This may be beneficial for reducing the number of learnable parameters for each entity of the entire machine learning system. For example, the above-mentioned exponential time decay weights can be fixed (or learned) and shared across multiple entities, while the state data may be unique for each entity.

[0216] Training machine learning systems to process transaction data

[0217] In some examples, a machine learning system (such as the one described herein) can be trained using labeled training data. For example, a training set can be provided that includes data associated with transactions that have been labeled as "normal" or "fraudulent". In one case, these labels can be provided based on reported fraudulent activity, i.e., using past fraud reports. For example, data associated with transactions that have been approved and processed without subsequent fraud reports can be labeled as "0" or "normal"; while data associated with transactions that have been rejected and / or that were later reported as fraudulent and otherwise labeled or blocked can be labeled as "1" or abnormal.

[0218] An end-to-end training process can be performed so that the machine learning system can learn appropriate values ​​for any and all learnable parameters. This can, for example, include training parameters of any multilayer perceptron and / or decay weights for a decay function. It will be appreciated that any suitable training algorithm known in the art itself can be used, and the principles of the present invention are not limited to any particular training algorithm. However, by way of example, a suitable training algorithm can be based on stochastic gradient descent, and the model parameters can be iteratively improved using back propagation of errors in the model predictions in order to find model parameters that minimize an objective function. In one case, the objective function (which measures the error in the model predictions) can be defined as a binary cross entropy between the predicted value 602 and the ground truth label ("0" or "1").

[0219] Those skilled in the art will understand that, where reference is made to the various rows and columns of a state data table, the respective roles of these rows and columns may be swapped such that the state data is stored in rows indexed by category identifiers, while the state data values ​​for the various features are stored in columns.

[0220] It will be appreciated that embodiments of the invention may provide an arrangement in which the classification history module brings signal extraction from interaction monitoring into the architecture. Advantageously, this may result in improvements in speed and / or confidentiality of implementation. Specifically, data scientists no longer need to manually design features of this type, which means that they do not need to be exposed as input to the classifier for model management, and implementation time of the model is reduced.

[0221] In addition, embodiments of the present invention may provide improvements in detection performance. The classification history module may learn more subtle interaction logic than humans can manually design in a limited time. Specifically, the classification history module may learn patterns of user activity specific to each category and detect anomalies based on historical data of related entity-category pairs. This method may provide significant detection enhancement relative to other methods known per se in the art.

[0222] Although specific embodiments of the present invention have been described in detail, those skilled in the art will appreciate that the described embodiments do not limit the scope of the invention as claimed.

Claims

1. A machine learning system for processing data corresponding to incoming transactions associated with an entity, the machine learning system comprising a classification history module, the classification history module configured to process at least some of the data, the classification history module comprising: i) a memory configured to store state data for a plurality of categories indexed by respective category identifiers, wherein the state data stored in the memory for each category identifier corresponds to a previous transaction associated with the entity and the respective category; ii) a decay logic stage configured to modify state data stored in the memory based on a time difference between the time of the incoming transaction and the time of a previous transaction, the decay logic stage being configured to: a) when the memory contains state data for an entity and class identifier pair associated with the incoming transaction, retrieving the state data and applying a decay function to the state data to generate a decayed version of the state data, wherein the decay function depends on the time difference, and outputting a decayed version of the state data; and iii) an update logic stage configured to: update the state data output from the decay logic stage using an input tensor generated from data corresponding to the incoming transaction to generate updated state data; store the updated state data in the memory for the entity and class identifier pair associated with the incoming transaction; and output an output tensor including the updated state data; iv) wherein the machine learning system is configured to map the output tensor from the classification history module to a scalar value representing the likelihood that the incoming transaction presents an anomaly within a sequence of actions; and v) wherein the scalar value is used to determine whether to approve or reject the incoming transaction.

2. The machine learning system according to claim 1, wherein: The attenuation logic stage is also configured to: b) when the memory does not contain state data for the entity and class identifier pair associated with the incoming transaction, generating new state data and outputting the new state data.

3. The machine learning system according to claim 1 or 2, further comprising: A first neural network stage is configured to apply a neural network layer having a corresponding plurality of learned weights to data corresponding to the incoming transaction to generate the input tensor, and to provide the input tensor to the update logic stage of the classification history module.

4. A machine learning system according to any preceding claim, further comprising: a second neural network stage configured to apply a second neural network layer having a corresponding plurality of learned weights to the output tensor generated by the update logic stage of the classification history module to generate the scalar value representing a likelihood that the incoming transaction presents an anomaly within the sequence of actions.

5. A machine learning system according to any preceding claim, wherein: The update logic level includes: a third neural network stage configured to generate said updated state data using said decayed state data and said input tensor derived from said incoming transaction; Optionally, the third neural network level comprises a recursive neural network.

6. A machine learning system according to any preceding claim, wherein: The decay logic stage is configured to modify state data of the entity stored in the memory associated with the incoming transaction based on a time difference between a time of the incoming transaction and a time of a most recent transaction of the entity.

7. The machine learning system according to any one of claims 1 to 5, wherein: The decay logic stage is configured to modify all state data for each entity stored in the memory based on a time difference between the time of the incoming transaction and the time of an immediately preceding transaction.

8. The machine learning system according to any one of claims 1 to 5, wherein: The decay logic stage is configured to modify only the state data stored in the memory for the entity and category identifier pair associated with the incoming transaction, wherein the decay logic stage modifies the state data based on a time difference between a time of the incoming transaction and a time of a previous transaction of the entity and category identifier pair associated with the incoming transaction.

9. A machine learning system according to any preceding claim, wherein: The memory is configured as a stack such that the retrieved state data is removed from the stack and such that updated state data is stored at the top of the stack.

10. A machine learning system according to any preceding claim, wherein: The classification history module is configured such that when the memory is full, the status data stored for at least one category identifier is erased.

11. The machine learning system according to claim 10, wherein: The classification history module is configured such that when the memory is full, the state data stored for the least recently seen category identifier is erased.

12. A machine learning system according to any preceding claim, wherein: The state data stored for each entity and class identifier pair comprises a tensor of values.

13. The machine learning system of claim 12, wherein: The decay function applies a corresponding decay multiplier to each of the values.

14. The machine learning system of claim 13, wherein: At least some of the attenuation multipliers are learned.

15. A machine learning system according to any preceding claim, further comprising: A time decay unit module configured to process at least some of the data corresponding to the incoming transaction, the time decay unit module comprising: a second memory configured to store second state data corresponding to an immediately preceding transaction; and A second decay logic stage is configured to modify the second state data stored in the second memory based on a time difference between a time of the incoming transaction and a time of the immediately preceding transaction.

16. The machine learning system of claim 15, wherein: The time decay unit module also includes: a fourth neural network stage configured to determine next state data using previous state data modified by the second decay logic stage and a second input tensor derived from the incoming transaction, the fourth neural network stage configured to store the next state data in the second memory; Optionally, wherein the fourth neural network level comprises a recursive neural network.

17. A machine learning system according to claim 15 or 16, wherein: The machine learning system is configured to map output data from both the time decay unit module and the classification history module to the scalar value representing the likelihood that the incoming transaction presents an anomaly within a sequence of actions.

18. A machine learning system according to any preceding claim, wherein: The memory is configured to store state data for a plurality of entities, wherein, for each entity, a plurality of categories indexed by respective category identifiers are stored, wherein the state data stored in the memory for each category identifier corresponds to a previous transaction associated with the respective entity and the respective category.

19. A machine learning system according to any preceding claim, wherein: Each of the plurality of categories includes one or more of: secondary entity; secondary entity type; transaction value; transaction value range; day of the week; time of the day; hour of the day; and time window.

20. The machine learning system of claim 19, wherein: One or more of the plurality of categories comprises a composite of one or more of: secondary entity; secondary entity type; transaction value; transaction value range; day of the week; time of the day; hour of the day; and time window.

21. A method of processing data associated with a proposed transaction associated with an entity, the method comprising: i) storing in a memory state data for a plurality of categories indexed by respective category identifiers, wherein the state data stored in the memory for each category identifier corresponds to a previous transaction associated with the entity and the respective category; ii) modifying the state data stored in the memory based on the time difference between the time of the incoming transaction and the time of the previous transaction, wherein the step of modifying the state data comprises: a) when the memory contains state data for an entity and class identifier pair associated with the incoming transaction, retrieving the state data and applying a decay function to the state data to generate a decayed version of the state data, wherein the decay function depends on the time difference, and outputting a decayed version of the state data; and iii) updating the output of the state data using an input tensor generated from data corresponding to the incoming transaction to generate updated state data; storing the updated state data in the memory for the entity and class identifier pair associated with the incoming transaction; and outputting an output tensor including the updated state data; iv) mapping the output tensor to a scalar value representing the likelihood that the incoming transaction is an anomaly within an action sequence; and v) using the scalar value to determine whether to approve or reject the incoming transaction.

22. The method according to claim 21, further comprising: Applying a neural network layer having a corresponding plurality of learned weights to the data corresponding to the incoming transaction to generate the input tensor.

23. The method according to claim 21 or 22, further comprising: A second neural network layer having a corresponding plurality of learned weights is applied to the output tensor to generate the scalar value representing a likelihood that the incoming transaction is an anomaly within a sequence of actions.

24. A method according to any one of claims 21 to 23, comprising: The state data stored in the memory for an entity associated with the incoming transaction is modified based on a time difference between a time of the incoming transaction and a time of a most recent transaction of the entity.

25. A method according to any one of claims 21 to 23, comprising: All state data stored in the memory for each entity is modified based on the time difference between the time of the incoming transaction and the time of the immediately preceding transaction.

26. A method according to any one of claims 21 to 23, comprising: Only state data stored in the memory for the entity and category identifier pair associated with the incoming transaction is modified, wherein the decay logic stage modifies the state data based on a time difference between a time of the incoming transaction and a time of a previous transaction of the entity and category identifier pair associated with the incoming transaction.

27. A method of processing data associated with a proposed transaction, the method comprising: receiving an incoming event from a client transaction processing system, the incoming event associated with a request for an approval decision for a proposed transaction; parsing the incoming events to extract data for the proposed transaction, including determining a time difference between the proposed transaction and a prior transaction; applying the machine learning system of any one of claims 1 to 17 to output a scalar value representing a likelihood that the proposed transaction presents an anomaly within the sequence of actions based on the extracted data and the time difference, the applying comprising accessing the memory to retrieve at least state data for entity and category identifiers associated with the transaction; determining a binary output based on the scalar value output by the machine learning system, the binary output representing whether the proposed transaction is approved or denied; as well as The binary output is returned to the client transaction processing system.

28. A classification history module for use in a machine learning system for processing data corresponding to incoming transactions associated with an entity, the classification history module being configured to process at least some of the data, the classification history module comprising: i) a memory configured to store state data for a plurality of categories indexed by respective category identifiers, wherein the state data stored in the memory for each category identifier corresponds to a previous transaction associated with the entity and the respective category; ii) a decay logic stage configured to modify state data stored in the memory based on a time difference between the time of the incoming transaction and the time of a previous transaction, the decay logic stage being configured to: a) when the memory contains state data for an entity and class identifier pair associated with the incoming transaction, retrieving the state data and applying a decay function to the state data to generate a decayed version of the state data, wherein the decay function depends on the time difference, and outputting a decayed version of the state data; and iii) an update logic stage configured to: update the state data output from the decay logic stage using an input tensor generated based on data corresponding to the incoming transaction to generate updated state data; store the updated state data in the memory for the entity and category identifier pair associated with the incoming transaction; and output an output tensor including the updated state data.

29. A method of processing data associated with a proposed transaction associated with an entity, the method comprising: i) storing in a memory state data for a plurality of categories indexed by respective category identifiers, wherein the state data stored in the memory for each category identifier corresponds to a previous transaction associated with the entity and the respective category; ii) modifying the state data stored in the memory based on the time difference between the time of the incoming transaction and the time of the previous transaction, wherein the step of modifying the state data comprises: a) when the memory contains state data for an entity and class identifier pair associated with the incoming transaction, retrieving the state data and applying a decay function to the state data to generate a decayed version of the state data, wherein the decay function depends on the time difference, and outputting a decayed version of the state data; and iii) updating the output of the state data using an input tensor generated from data corresponding to the incoming transaction to generate updated state data; storing the updated state data in the memory for the entity and category identifier pair associated with the incoming transaction; and outputting an output tensor including the updated state data.

30. A non-transitory computer readable medium comprising instructions which, when executed by a processor, cause the processor to perform the method of any one of claims 21 to 27 or claim 29.

Images