Training machine learning systems for transactional data processing

Abstract

A method for training a supervised machine learning system to detect anomalies in transactional data is described, the method including obtaining a training set of data samples, assigning a label indicative of the absence of anomalies to unlabeled data samples in the training set, partitioning data from the data samples in the training set into two feature sets, where a first feature set represents observable features and a second feature set represents contextual features, generating synthetic data samples by combining features from the two feature sets that respectively relate to two different uniquely identifiable entities, assigning a label indicative of the presence of anomalies to the synthetic data samples, augmenting the training set with the synthetic data samples, and training the supervised machine learning system using the augmented training set and the assigned labels.

Description

[Technical Field]

[0001] SYSTEMS AND METHODS FOR APPLYING MACHINE LEARNING SYSTEMS TO TRANSACTION DATA FIELD OF THE INVENTION Some examples relate to machine learning systems for use in real-time transaction processing. Some examples relate to methods for training machine learning systems for use in real-time transaction processing. [Background technology]

[0002] Digital payments have proliferated over the last two decades, with over three-quarters of global payments now using some form of payment card or electronic wallet. Point-of-sale systems are becoming increasingly digital rather than cash-based. Put simply, global systems of commerce now rely heavily on electronic data processing platforms. This presents many engineering challenges that are largely hidden from the lay user. For example, digital transactions must be completed in real time, i.e., with the minimum level of delay encountered by a computing device at the point of purchase. Digital transactions also need to be secure and resistant to attack and exploitation. The processing of digital transactions is also constrained by the historical development of global electronic systems for payments. For example, much infrastructure is still built around a model designed for mainframe architectures used more than 50 years ago.

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

[0004] While risks such as fraud are an economic issue for businesses involved in commerce, implementing technology systems to process transactions is an engineering challenge. Traditionally, banks, retailers, and card issuers developed “paper” rules or procedures, manually implemented by clerks, to communicate or block some transactions. As transactions became digital, one approach to building technology systems to process transactions became to provide these sets of developed standards to computer engineers and ask them to implement them using a digital representation of the transaction, i.e., to translate the handwritten rules into coded logic statements that can be applied to electronic transaction data. This traditional approach ran into several problems as digital transaction volumes grew. First, any processing applied needed to occur in “real time,” e.g., with millisecond latency. Second, loads fluctuate unpredictably over time (e.g., the launch of a new product or a set of tickets can easily increase average load levels several times), and thousands of transactions need to be processed per second (e.g., a typical "load" can be 1,000-2,000 per second). Third, transaction processors and banks' digital storage systems are often siloed or compartmentalized for security reasons, and digital transactions often require an interconnected web of commercial systems. Fourth, large-scale analysis of reported actual and predicted fraud is now possible. This shows that traditional approaches to fraud detection fall short, finding low accuracy and high false positives. This, in turn, has a physical impact on digital transaction processing: more genuine point-of-sale and online purchases are rejected, and those seeking to exploit the new digital systems often run off with it.

[0005] In recent years, more and more machine learning techniques have been applied to transactional data processing. As machine learning models have matured in academia, engineers have begun to attempt to apply them to transactional data processing. However, this again runs into problems. Even when engineers are provided with an academic or theoretical machine learning model and asked to implement it, this is not easy. For example, the problem of large-scale transaction processing systems comes into play. Machine learning models do not have the luxury of unlimited estimation time as in a laboratory. This means that some models are simply impractical to implement in a real-time setting, or they require significant adaptation to enable real-time processing at the volume levels encountered by real-world servers. Furthermore, engineers must contend with the problem of implementing machine learning models on siloed or compartmentalized data based on access security and in situations where the rate of data update is extreme. Thus, the problems faced by engineers building transactional processing systems can be seen as similar to those faced by network or database engineers, where machine learning models must be applied while meeting system throughput and query response time constraints set by the processing infrastructure. There are no easy solutions to these problems. Indeed, the fact that many transaction processing systems are confidential, proprietary, and based on older technologies means that engineers lack a developed body of knowledge within these adjacent fields and often face challenges unique to the transaction processing domain. Moreover, the field of large-scale practical machine learning remains relatively young, with few established design patterns or textbooks on which engineers can draw. [Prior art documents] [Non-patent literature]

[0006] [Non-Patent Document 1] "Attention is All You Need," Vaswani et al., arXiv, December 6, 2017 [Non-patent document 2] "Variational Autoencoder based Anomaly Detection using Reconstruction Probability," An and Cho, SNU Data Mining Center, 2015-2 Special Lecture at IE [Non-patent document 3] Chawla et al., Journal of Artificial Intelligence Research 16 (2002) 321~357 [Non-patent document 4] Ratner et al., "Snorkel: Rapid Training Data Creation with Weak Supervision," arXiv, November 28, 2017. Summary of the Invention [Means for solving the problem]

[0007] Aspects of the invention are set out in the accompanying independent claims. Some variations of the invention are then set out in the accompanying dependent claims. Further aspects, variations and examples are set out in the following detailed description.

[0008] Examples of the present invention will now be described, by way of example only, with reference to the accompanying drawings in which: [Brief explanation of the drawings]

[0009] [Figure 1A] FIG. 1 is a schematic diagram illustrating various exemplary electronic infrastructures for transaction processing. [Figure 1B] FIG. 1 is a schematic diagram illustrating various exemplary electronic infrastructures for transaction processing. [Figure 1C] FIG. 1 is a schematic diagram illustrating various exemplary electronic infrastructures for transaction processing. [Figure 2A]1A-1D are schematic diagrams illustrating various examples of data storage systems for use by a machine learning transaction processing system. [Figure 2B] 1A-1D are schematic diagrams illustrating various examples of data storage systems for use by a machine learning transaction processing system. [Figure 3A] 1 is a schematic diagram showing various examples of transaction data; [Figure 3B] 1 is a schematic diagram showing various examples of transaction data; [Figure 4] FIG. 1 is a schematic diagram illustrating example components of a machine learning transaction processing system. [Figure 5A] FIG. 2 is a sequence diagram illustrating an example set of processes performed by various computing entities on transaction data. [Figure 5B] FIG. 2 is a sequence diagram illustrating an example set of processes performed by various computing entities on transaction data. [Figure 6A] FIG. 1 is a schematic diagram illustrating a set of exemplary components for a first configuration of a machine learning system for processing transaction data. [Figure 6B] FIG. 6B is a schematic diagram illustrating a first stage for the example machine learning system of FIG. 6A. [Figure 6C] FIG. 6C is a schematic diagram illustrating a second stage for the example machine learning system of FIG. 6B. [Figure 7] FIG. 1 is a schematic diagram illustrating a set of exemplary components for a second configuration of a machine learning system for processing transaction data. [Figure 8] FIG. 1 is a schematic diagram illustrating an exemplary training configuration for a machine learning system. [Figure 9] FIG. 1 is a schematic diagram illustrating an example machine learning system adapted for a method of training using synthetic data samples. [Figure 10] FIG. 1 is a schematic diagram illustrating a processing pipeline for generating synthetic data samples according to an example. [Figure 11A] FIG. 2 is a schematic diagram illustrating an exemplary portion of a set of transaction data. [Figure 11B] FIG. 2 is a schematic diagram illustrating an exemplary feature vector. [Figure 12] 1 is a flowchart illustrating an example method for training a machine learning system using synthetic data samples. [Figure 13] 1 is a flowchart illustrating an exemplary method for applying a machine learning system. DETAILED DESCRIPTION OF THE INVENTION

[0010] introduction Some examples described herein relate to machine learning systems for use in transaction processing. In some examples, machine learning systems are applied in real-time, high-volume transaction processing pipelines to provide an indication of whether a transaction or entity conforms to previously observed and / or predicted patterns of activity or action, e.g., whether the transaction or entity is “normal” or “anomalous.” The term “behavioral” is used herein to refer to this pattern of activity or action. The indication may comprise a scalar value that is normalized within a predetermined range (e.g., 0 to 1) and can then be used to prevent fraud and other misuse of the payment system. The machine learning system may apply machine learning models that are updated as more transaction data is acquired, e.g., continually trained based on new data, to reduce false positives and maintain accuracy of output metrics. This example may be particularly useful for preventing fraud in cases where the physical presence of a payment card cannot be confirmed (e.g., online transactions known as “card-not-present”) or for commercial transactions where high-value transactions may be routine and where it may be difficult to classify behavioral patterns as “unexpected.” Thus, the present example facilitates the processing of transactions as these transactions become primarily "online," ie, conducted digitally over one or more public communications networks.

[0011] Some examples described herein allow machine learning models to be tailored to be specific to certain entities, such as account holders and merchants. For example, the machine learning models may model entity-specific patterns of behavior rather than general swarm or aggregate behavior, which can result in poor accuracy. The machine learning systems described herein can provide machine learning models that dynamically update despite large transaction flows and / or the need for isolation of various data sources.

[0012] This example may be applied to a wide variety of digital transactions, including but not limited to card payments, so-called "wire" transfers, peer-to-peer payments, Bankers' Automated Clearing System (BACS) payments, and Automated Payment Processor (ACH) payments. The output of the machine learning system may be used to prevent a wide variety of fraudulent and criminal behavior, such as card fraud, application fraud, payment fraud, retail fraud, gaming fraud, and money laundering.

[0013] Current exemplary machine learning systems, for example, as configured and / or trained according to Figures 1A-13 below, enable fast inference that can be easily parallelized to provide one-second or sub-second processing latencies and to manage large-scale processing volumes (e.g., billions of transactions per year).

[0014] Two specific embodiments are described below. FIGS. 1A-5B provide context for both embodiments. The first embodiment relates to a machine learning system in the form of a particular neural network architecture, as shown in FIGS. 6A-6C. The second embodiment relates in detail to a method of training a machine learning system, and is described with reference to FIGS. 9-13. The first and second embodiments may preferably be applied separately and independently. For example, FIGS. 7 and 8 provide examples of alternative machine learning systems that may be trained according to the second embodiment, and FIG. 8 illustrates an alternative method for training a machine learning system described with reference to the first embodiment. However, in some cases, they may be applied together, e.g., the training method of the second embodiment may be applied to train a machine learning system of the first embodiment. Both embodiments offer certain technical advantages compared to other systems and methods, which are described in the following text.

[0015] Some term definitions The term "data" is used in various contexts herein to refer to digital information, such as that represented by known bit structures in one or more programming languages. In use, data may refer to digital information stored as a bit sequence in computer memory. Some machine learning models may operate on structured arrays of data in a predefined bit format. Using the terminology of the art, these may be referred to as multidimensional arrays or "tensors." Note that for machine learning methods, multidimensional arrays, e.g., having defined ranges in multiple dimensions, may be "flattened" so as 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). Thus, as used herein, the term "tensor" covers multidimensional arrays having one or more dimensions (e.g., vectors, matrices, arrays of capacitance measurements, etc.).

[0016] The term "structured numeric representation" is used to refer to numerical data in a structured form, such as an array of one or more dimensions that stores numerical values ​​having a common data type, such as integer or float values. A structured numeric representation may comprise a tensor (as used in machine learning terminology). A structured numeric representation is typically stored as an indexed and / or contiguous set of memory locations; for example, a one-dimensional array of 64-bit floats may be represented in computer memory as a contiguous sequence of 64-bit memory locations in a 64-bit computing system.

[0017] The term "transaction data" is used herein to refer to electronic data related to a transaction. A transaction comprises a series of communications between different electronic systems to effect a payment or exchange. Generally, transaction data may comprise data indicative of events (e.g., actions undertaken in a timely manner) that are relevant to and may be beneficial to transaction processing. Transaction data may comprise structured data, unstructured data, and semi-structured data. Transaction data may also include data related to a transaction, such as data used to process the transaction. In some cases, transaction data may be used broadly to refer to actions taken with respect to one or more electronic devices. Transaction data may take various forms depending on the exact implementation. However, various data types and formats may be converted by pre- or post-processing, as appropriate.

[0018] The term “interface” is used herein to refer to any physical and / or logical interface that enables one or more of data input and data output. An interface may be implemented by a network interface adapted to send and / or receive data or by retrieving data from one or more memory locations as performed by a processor executing a set of instructions. An interface may also comprise a physical (network) connection through which data is received, such as hardware for enabling wired or wireless communication over a particular medium. An interface may comprise an application programming interface and / or a method call or method return. For example, in a software implementation, an interface may comprise passing data and / or memory references to a function initiated via a method call, where the function comprises computer program code executed by one or more processors; in a hardware implementation, an interface may comprise a wired interconnect between different chips, chipsets, or portions of a chip. In drawings, an interface may be indicated by the boundary of a processing block with inward and / or outward arrows representing data transfer.

[0019] The terms "component" and "module" are used interchangeably to refer to either a hardware structure having 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., specific computer program code running on one or more general-purpose processors). A component or module may be implemented as a specific packaged chipset, e.g., 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., as executed in use by a processor.

[0020] The term "machine learning model" is used herein to refer to at least a hardware-implemented implementation of a machine learning model or function. Known models within the field of machine learning include logistic regression models, naive Bayes models, random forests, support vector machines, and artificial neural networks. Classifier implementations may be made within one or more machine learning programming libraries, including, but not limited to, scikit-learn, TensorFlow, and PyTorch.

[0021] The term "mapping" is used herein to refer to the 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, with the output array having a smaller dimensionality than the input array. The input and output arrays may have a common or different data type. In some examples, the mapping is a one-way mapping to a scalar value.

[0022] The term "neural network architecture" refers to a set of one or more artificial neural networks configured to perform a specific data processing task. For example, a "neural network architecture" may comprise a specific configuration of one or more neural network layers of one or more neural network types. Neural network types include convolutional neural networks, recurrent neural networks, and feedforward neural networks. Convolutional neural networks involve the application of one or more convolution operations. Recurrent neural networks involve internal states that are updated during a sequence of inputs. Thus, recurrent neural networks are viewed as including a form of recurrent or feedback connection, whereby the state of the recurrent neural network at a given time or iteration (e.g., t) is updated using the state of the recurrent neural network at a previous time or iteration (e.g., t-1). Feedforward neural networks involve transformation operations without feedback, e.g., operations are applied in a unidirectional sequence from input to output. Feedforward neural networks are sometimes called simple "neural networks," "multilayer perceptrons," "fully connected" neural networks, or "dense," "linear," or "deep" neural networks (the latter when they comprise multiple neural network layers in series). Some examples described herein utilize recurrent neural networks and fully connected neural networks.

[0023] A "neural network layer," as typically defined within machine learning programming tools and libraries, may be considered an operation that maps input data to output data. A "neural network layer" may apply one or more parameters, such as weights, to map input data to output data. One or more bias terms may also be applied. The weights and biases of a neural network layer may be applied using one or more multidimensional arrays or matrices. Generally, a neural network layer has multiple parameters whose values ​​affect how the layer maps input data to output data. These parameters may be trained in a supervised manner by optimizing an objective function, which typically involves minimizing a loss function. Some parameters may also be pre-trained or fixed in another manner. The fixed parameters may be considered configuration data that control the operation of the neural network layer. A neural network layer or neural network architecture may comprise a mixture of fixed and learnable parameters. A recurrent neural network layer may apply a series of operations to update the recurrent state and transform input data. The update of the recurrent state and the transformation of the input data may involve one or more transformations of the previous recurrent state and the input data. A recurrent neural network layer may be trained by deploying modeled recurrent units so that it can be applied within machine learning programming tools and libraries. Although a recurrent neural network may appear to comprise several (sub)layers to which various gating operations should be applied, most machine learning programming tools and libraries refer to the application of a recurrent neural network as a whole as a "neural network layer," and this convention will be followed here. Finally, a feedforward neural network layer may apply one or more sets of weights and biases to input data to generate output data. This operation may be expressed as a matrix operation (e.g., where a bias term can be included by adding a value of 1 onto the input data).Alternatively, the bias may be applied through a separate addition operation. As explained above, the term "tensor" is used to refer to an array that may have multiple dimensions, such as in machine learning libraries; for example, a tensor may comprise a vector, a matrix, or a data structure with a higher dimensionality. In a preferred example, the tensor described may comprise a vector with a predetermined number of elements.

[0024] To model complex nonlinear functions, neural network layers as described above may be followed by nonlinear activation functions. Common activation functions include the sigmoid function, the hyperbolic tangent function, and the rectified linear unit (RELU). Many other activation functions exist and can be applied. The activation function may be selected based on testing and preference. The activation function may be omitted in some circumstances and / or may form part of the internal structure of the neural network layer.

[0025] The exemplary neural network architectures described herein may be configured through training. In some cases, “learnable” or “trainable” parameters may be trained using a technique called backpropagation. During backpropagation, the neural network layers that make up each neural network architecture are initialized (e.g., with randomized weights) and then used to make predictions using a set of input data from a training set (e.g., a so-called “forward” pass). The predictions are used to evaluate a loss function. For example, a “ground truth” output may be compared to a predicted output, and the difference may form part of the loss function. In some examples, the loss function may be based on the absolute difference between a predicted scalar value and a binary ground truth label. The training set may comprise a set of transactions. When gradient descent is used, the loss function is used to determine the gradient of the loss function with respect to the parameters of the neural network architecture, where the gradient is then used to backpropagate updates to the parameter values ​​of the neural network architecture. Typically, the updates are propagated according to the derivatives of the neural network layer weights. For example, the gradient of the loss function with respect to the weights of a neural network layer may be determined and used to determine updates to the weights that minimize the loss function. In this case, optimization techniques such as gradient descent, stochastic gradient descent, Adam, etc. may be used to adjust the weights. Chain rules and autodifferentiation functions may be applied to efficiently compute the gradient of the loss function by working backward through the neural network layers in order.

[0026] Exemplary Transaction Processing System 1A-1C illustrate a set of exemplary transaction processing systems 100, 102, 104. These exemplary transaction processing systems are described to provide a context for the inventions described herein but should not be viewed as limiting, and the configuration of any one implementation may vary based on the specific requirements of that implementation. However, the exemplary transaction processing systems described will enable one skilled in the art to identify several high-level technical features that are important to the following discussion. The three exemplary transaction processing systems 100, 102, 104 illustrate various areas in which variations may occur.

[0027] 1A-1C illustrate a set of client devices 110 configured to initiate transactions. In this example, the set of client devices 110 includes a smartphone 110-A, a computer 110-B, a point-of-sale (POS) system 110-C, and a portable commercial device 110-D. These client devices 110 provide a non-exhaustive set of examples. In general, any electronic device or set of devices may be used to initiate a transaction. In some cases, the transaction comprises a purchase or payment. For example, the purchase or payment may be an online or mobile purchase or payment made through smartphone 110-A or computer 110-B, or may be a purchase or payment made at a commercial store, such as via POS system 110-C or portable commercial device 110-D. The purchase or payment may be for goods and / or services.

[0028] 1A-1C, 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 by one or more wired and / or wireless networks, including telecommunications networks. In a preferred example, all communications across the one or more computer networks are secured using, for example, the Transport Layer Security (TLS) protocol. In FIG. 1A, two computer networks are shown as 120-A and 120-B. These may be separate networks or different portions of a common network. First computer network 120-A communicatively couples client device 110 to commerce server 130. Commerce server 130 may execute computer processes that implement process flows for transactions. For example, commerce server 130 may be a back-end server that processes transaction requests received from point-of-sale system 110-C or portable commerce device 110-D, or may be used by an online retailer to implement a website where purchases can be made. It will be appreciated that the example of Figures 1A-1C is a necessary simplification of an actual architecture, and that there may be several interacting server devices implementing an online retailer, including, for example, separate server devices for providing HyperText Markup Language (HTML) pages detailing products and / or services and for handling payment processes.

[0029] In FIG. 1A, the commerce server 130 is communicatively coupled to a further set of backend server devices for processing transactions. In FIG. 1A, the commerce server 130 is communicatively coupled to a payment processor server 140 via a second network 120-B. The payment processor server 140 is communicatively coupled to a first data storage device 142 that stores transaction data 146 and a second data storage device 144 that stores auxiliary data 148. The transaction data 146 may comprise batches of transaction data relating to various transactions undertaken over a period of time. The auxiliary data 148 may comprise data related to the transactions, such as records storing merchant data and / or end-user data. In FIG. 1A, the payment processor server 140 is communicatively coupled to a machine learning server 150 via the second network 120-B. The machine learning server 150 implements a machine learning system 160 for processing the transaction data. The machine learning system 160 is configured to receive input data 162 and map it to output data 164 used by the payment processor server 140 to process a particular transaction, such as a transaction originating from a client device 110. In some cases, the machine learning system 160 receives at least transaction data related to a particular transaction and provides an alert or numerical output used by the payment processor server 140 to determine whether the transaction should be permitted (i.e., approved) or denied. Thus, the output of the machine learning system 160 may comprise a label, alert, or other indication of fraudulent activity, or general malicious or anomalous activity. The output may comprise a probabilistic indication, such as a score or probability. In some cases, the output data 164 may comprise a scalar numeric value. The input data 162 may further comprise data derived from one or more of the transaction data 146 and the auxiliary data 148. In some cases, the output data 164 indicates a level of deviation from a particular expected pattern of behavior based on past observations or measurements.For example, this may indicate fraudulent or criminal behavior, often when it differs significantly, especially on a large scale, from observed patterns of behavior. The output data 164 may form a behavioral measurement. Expected patterns of behavior may be defined, either explicitly or implicitly, based on observed interactions between different entities in a transaction process flow, such as the end user or customer, the merchant (including point-of-sale and back-end locations or entities, if these may be different), and the bank.

[0030] The machine learning system 160 may be implemented as part of a transaction processing pipeline. An exemplary transaction processing pipeline is described below with respect to FIGS. 5A and 5B. The transaction processing pipeline may comprise electronic communications between the client device 110, the merchant server 130, the payment processor server 140, and the machine learning server 150. Other server devices may also be involved, such as a banking server that provides authorization from the issuing bank. In some cases, the client device 110 may communicate directly with the payment processor server 140. In use, the transaction processing pipeline must typically be completed within 100 or 200 milliseconds. Generally, processing times of less than one second may be considered real-time (e.g., humans typically perceive events in a time span of 400 ms). Furthermore, 100-200 ms may be the desired maximum latency of the total round-trip time for transaction processing, and within this time span, the time allocated for machine learning system 160 may be a small fraction of this total, such as 10 ms (i.e., less than 5-10% of the target processing time), when most of that time can be reserved for other operations in the transaction processing flow. This presents technical constraints for the implementation of machine learning system 160. Furthermore, in real-world implementations, the average processing volume may be on the order of 1000-2000 transactions per second. This means that most “off-the-shelf” machine learning systems are not suitable for implementing machine learning system 160. This further means that most machine learning techniques described in academic papers cannot be implemented within the above-mentioned transaction processing pipeline without nontrivial adaptation. Another problem is that anomalies, by their very nature, are rare events, and therefore accurate machine learning systems are difficult to train.

[0031] FIG. 1B shows a variation 102 of the exemplary transaction processing system 100 of FIG. 1A. In this variation 102, the machine learning system 160 is implemented within a payment processor computer infrastructure, e.g., executed by the payment processor server 140 and / or running on a locally coupled server in the same local network as the payment processor server 140. The variation 102 of FIG. 1B may be preferred for larger payment processors because it allows for faster response times, greater control, and improved security. Functionally, however, its transaction processing pipeline may be similar to that of FIG. 1A. For example, in the example of FIG. 1A, the machine learning system 160 may be initiated by a secure external application programming interface (API) call, such as a Representation State Transfer (REST) ​​API call using Hypertext Transfer Protocol Secure (HTTPS), whereas in FIG. 1B, the machine learning system 160 may be initiated by an internal API call, where a common end API may handle both requests (e.g., a REST HTTPS API may provide an external wrapper for the internal API).

[0032] FIG. 1C shows another variation 104 of the example transaction processing system 100 of FIG. 1A. 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 comprise a local storage network accessible to the machine learning server 150. In this case, there are multiple local data storage devices 170-A through 170-N, where each data storage device stores partitioned auxiliary data 172. The partitioned auxiliary data 172 may comprise parameters for one or more machine learning models. In some cases, the auxiliary data 172 may comprise state for the machine learning models, where the state may relate to a particular entity, such as a user or a merchant. The partitioning of the auxiliary data 172 may need to be applied to meet security requirements set by a third party, such as a payment processor, one or more banks, and / or one or more merchants. During use, machine learning system 160 accesses auxiliary data 172-A-172-N via multiple local data storage devices 170-A-170-N based on input data 162. For example, input data 162 may be received through an API request from a particular source and / or may comprise data identifying that a particular partition should be used to process the API request. More details of various storage systems that may be employed to meet security requirements are set forth in Figures 2A and 2B.

[0033] Exemplary Data Storage Configurations 2A and 2B illustrate two exemplary data storage configurations 200 and 202 that may be used by an exemplary machine learning system 210 for processing transaction data. The examples of FIGS. 2A and 2B are two non-limiting examples illustrating various options available for implementation, and a particular configuration may be selected according to individual circumstances. The machine learning system 210 may comprise an implementation of the machine learning system 160 described in the previous examples of FIGS. 1A-1C. The examples of FIGS. 2A and 2B, for example, enable the machine learning system 210 to process transaction data secured using heterogeneous cryptographic parameters to securely process transaction data for heterogeneous entities. It will be appreciated that the configurations of FIGS. 2A and 2B may not be used if the machine learning system 160 is implemented, for example, within an internal transaction processing system for a single set of secured transaction data and auxiliary data, or as a hosted system for use by a single payment processor.

[0034] FIG. 2A shows a machine learning system 210 communicatively coupled to a data bus 220. The data bus 220 may comprise 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 multiple data storage devices 230, 232. The data storage devices 230, 232 may comprise any known data storage device, such as magnetic hard disks and solid-state devices. While the data storage devices 230, 232 are shown as separate devices in FIG. 2A, they may alternatively form different physical areas or portions of storage within a common data storage device. In FIG. 2A, the multiple data storage devices 230, 232 store historical transaction data 240 and auxiliary data 242. In FIG. 2A, a first set of data storage devices 230 stores historical transaction data 240, and a second set of data storage devices 232 stores auxiliary data 242. Ancillary data 242 may comprise one or more of model parameters for a set of machine learning models (such as trained parameters for a neural network architecture and / or configuration parameters for a random forest model) and state data for those models. In some cases, different sets of historical transaction data 240-A-N and auxiliary data 242-A-N are associated with different entities that securely and collectively use the services provided by machine learning system 210; for example, they may represent data for various banks that need to be kept separate as part of the terms of providing machine learning services to those entities.

[0035] FIG. 2B illustrates another manner in which different sets of historical transaction data 240-A-N and auxiliary data 242-A-N may be stored. In FIG. 2B, machine learning system 210 is communicatively coupled to at least one data storage device 260 via data transfer channel 250. Data transfer channel 250 may comprise a local storage bus, a local storage area network, and / or a remote secure storage coupling (e.g., overlaid on top of an insecure network such as the Internet). In FIG. 2B, secure logical storage layer 270 is provided using physical data storage device 260. Secure logical storage layer 270 may be a virtualized system that appears to machine learning system 210 as a separate physical storage device while actually being implemented independently of at least one data storage device 260. Logical storage layer 270 may provide separate encrypted partitions 280 for data relating to groups of entities (e.g., relating to various issuing banks, etc.), and different sets of historical transaction data 240-A-N and auxiliary data 242-A-N may be stored in corresponding partitions 280-A-N. In some cases, entities may be created dynamically as transactions are received for processing based on data stored by one or more of the server systems shown in Figures 1A-1C.

[0036] Example Transaction Data 3A and 3B show examples of transaction data that may be processed by a machine learning system such as 160 or 210. FIG. 3A shows how the transaction data may comprise a set of chronologically ordered records 300, where each record has a timestamp and comprises multiple transaction fields. In some cases, the transaction data may be grouped and / or filtered based on the timestamps. For example, FIG. 3A shows the partitioning of the transaction data into current transaction data 310 related to the current transaction and “older” or historical transaction data 320 that falls within a predetermined time range of the current transaction. The time range may be set as a hyperparameter of any machine learning system. Alternatively, the “older” or historical transaction data 320 may be set as some number of transactions. A mixture of the two approaches is also possible.

[0037] 3B illustrates how transaction data 330 for a particular transaction may be stored in a numeric format for processing by one or more machine learning models. For example, in FIG. 3B, the transaction data has at least the following fields: transaction amount, timestamp (e.g., as a Unix epoch), transaction type (e.g., card payment or direct debit), product description or product identifier (i.e., relating to the item being purchased), merchant identifier, issuing bank identifier, character set (e.g., Unicode characters in a field of a predetermined character length), country identifier, etc. Note that a wide variety of data types and formats may be received and preprocessed into an appropriate numeric representation. In some cases, incoming transaction data, such as transaction data generated by a client device and sent to commerce 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 is being performed, and the manner in which the transaction is being performed (e.g., in person, over the phone, on a website).

[0038] Exemplary Machine Learning System FIG. 4 shows an example 400 of a machine learning system 402 that may be used to process transaction data. The machine learning system 402 may implement one or more of the machine learning systems 160 and 210. The machine learning system 402 receives input data 410. The format of the input data 410 may depend on which machine learning model is being applied by the machine learning system 402. If the machine learning system 402 is configured to perform fraud detection or anomaly detection with respect to a transaction, e.g., an ongoing transaction as described above, the input data 410 may comprise transaction data (i.e., data that forms part of the data package for the transaction), such as 330, as well as data derived from historical transaction data (e.g., 300 in FIG. 3A) and / or auxiliary data (e.g., 148 in FIGS. 1A-1C or 242 in FIGS. 2A and 2B). The auxiliary data may comprise secondary data linked to one or more entities identified in the primary data related to the transaction. For example, if the transaction data for an ongoing transaction identifies a user, a merchant, and one or more banks (such as an issuing bank for the user and a commercial bank) associated with the transaction, such as through unique identifiers present in the transaction data, the auxiliary data may comprise data related to these transaction entities. The auxiliary data may also comprise data derived from activity records, such as interaction logs and / or authentication records. In some cases, the auxiliary data is stored in one or more static data records and is retrieved from these records based on the received transaction data. Additionally or alternatively, the auxiliary data may comprise machine learning model parameters that are retrieved based on the content of the transaction data. For example, the machine learning model may have parameters specific to one or more of the user, the merchant, and the issuing bank, and these parameters may be retrieved based on which of these are identified in the transaction data.For example, one or more of the users, merchants, and issuing banks may have corresponding embeddings that may comprise retrievable or mappable tensor representations for the entities. For example, each user or merchant may have a tensor representation (e.g., a floating-point vector of size 128-1024) that may either be retrieved from a database or other data storage or generated by an embedding layer, e.g., based on a user index or merchant index.

[0039] Input data 410 is received at an input data interface 412. The input data interface 412 may comprise an API interface, such as an internal or external API interface as described above. In some cases, the payment processor server 140, as shown in FIGS. 1A-1C, makes requests to this interface, where the request payload includes transaction data. The API interface may be defined to be agnostic with respect to the format or source of the transaction data. The input data interface 412 is communicatively coupled to a machine learning model platform 414. In some cases, requests made to the input data interface 412 trigger execution of the machine learning model platform 414 using the transaction data provided to the interface. The machine learning model platform 414 is configured as an execution environment for the application of one or more machine learning models to the input data 410. In some cases, the machine learning model platform 414 is configured as an execution wrapper for multiple different selectable machine learning models. For example, the machine learning models may be defined using a model definition language (e.g., similar to or using a markup language such as the Extensible Markup Language (XML)). The model definition language may include SQL, TensorFlow, Caffe, Thinc, and PyTorch (independently or in combination, among others). In some cases, the model definition language comprises computer program code executable to perform one or more of training and estimation of the defined machine learning model. The machine learning model may comprise, for example, an artificial neural network architecture, an ensemble model, a regression model, a decision tree such as a random forest, a graph model, and a Bayesian network, among others. One exemplary machine learning model based on an artificial neural network is described below with reference to FIGS. 6A-6C, and one exemplary machine learning model based on a random forest model is described below with reference to FIG. 7.The machine learning model platform 414 may define common (i.e., shared) input and output definitions such that different machine learning models are applied in a common (i.e., shared) manner.

[0040] In this example, the machine learning model platform 414 is configured to provide at least a single scalar output 416, which may be normalized within a predetermined range, such as between 0 and 1. Once normalized, the scalar output 416 may be viewed as a probability that a transaction associated with the input data 410 is fraudulent or anomalous. In this case, a value of “0” may represent a transaction that matches a normal pattern of activity for one or more of the user, merchant, and issuing bank, while a value of “1” may indicate that the transaction is fraudulent or anomalous, i.e., does not match an expected pattern of activity (although one skilled in the art will recognize that the normalized range may be different, such as inverted or within different boundaries, and have the same functional impact). Note that while the range of values ​​may be specified as between 0 and 1, the output values ​​may not be uniformly distributed within this range; for example, a value of “0.2” may be a common output for a “normal” event, while a value of “0.8” may be viewed as exceeding a threshold for a typical “anomalous” or fraudulent event. The machine learning models implemented by the machine learning platform 414 may thus implement some form of mapping between highly dimensional input data (e.g., transaction data and any retrieved auxiliary data) and single-value output. In some cases, for example, the machine learning platform 414 may be configured to receive input data for the machine learning models in a numeric format, and each defined machine learning model is configured to map the defined input data in a similar manner. The exact machine learning model applied by the machine learning model platform 414, and the parameters for that model, may be determined based on configuration data. The configuration data may be included in and / or identified using the input data 410, and / or set based on one or more configuration files parsed by the machine learning platform 414.

[0041] In some cases, the machine learning model platform 414 may provide additional outputs depending 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 explanation of the machine learning model's output in terms of the 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 influenced the model output—e.g., the combination of the “amount” channel exceeding a learned threshold and a set of “merchant” elements or units (e.g., embeddings or indexes) being outside a given cluster. If the machine learning model platform 414 implements decision trees, these additional outputs may comprise paths through the decision trees or aggregate feature importances based on an ensemble of trees. In the case of a neural network architecture, this may comprise layer output activations and / or layer filters with positive activations.

[0042] In FIG. 4 , some implementations may include an optional alert system 418 that receives the scalar output 416. In other implementations, the scalar output 416 may be passed directly to the output data interface 420 without post-processing. In the latter case, the scalar output 416 may be packaged within a response to the original request to the input data interface 412. In either case, 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 enable 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 deny the transaction. Depending on implementation requirements, in some cases, the alert system 418 may process the scalar output 416 and return a binary value indicating whether the transaction should be approved or denied (e.g., “1” equals deny). In some cases, a decision may be made by applying a threshold to the scalar output 416. This 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 explanatory data (e.g., the "reason code" described above) and / or the original input data. The output data interface 420 may generate an output data package for the output data 422 that combines these inputs with the scalar output 416 (e.g., at least for logging and / or later review). Similarly, the alerts generated by the alarm system 418 may include and / or be based on the additional inputs described above, in addition to the scalar output 416, for example.

[0043] In a preferred implementation, the machine learning system 402 is used in an “online” mode to process high-volume transactions within a narrowly defined time range. For example, under normal processing conditions, the machine learning system 402 may process requests within 7-12 ms and may be able to manage 1000-2000 requests per second (these are moderate constraints from real-world operating conditions). However, the machine learning system 402 may also be used in an “offline” mode, for example, by providing selected historical transactions to the input data interface 412. In offline mode, input data may be passed to the input data interface in batches (i.e., groups). The machine learning system 402 may also be capable of implementing machine learning models that provide scalar outputs for entities other than or in place of transactions. For example, the machine learning system 402 may receive requests related to an identified user (e.g., cardholder or payment account holder) or an identified merchant and may be configured to provide a scalar output 416 indicative of the likelihood (i.e., a general threat or risk) that the user or merchant is fraudulent, malicious, or anomalous. For example, this may form part of a continuous or periodic monitoring process, or a one-off request (e.g., as part of an application for a service). The provision of a scalar output for a particular entity may be based on the set of transaction data in a sequence of transaction data (e.g., transaction data for the entity similar to that to be in FIG. 3A) up to and including the last approved transaction.

[0044] Exemplary Transaction Process Flow 5A and 5B illustrate two possible exemplary transaction process flows 500 and 550. These process flows may occur in the context of the exemplary transaction processing systems 100, 102, and 104 shown in FIGS. 1A-1C, as well as other systems. Process flows 500 and 550 are provided as an example of a context in which a machine learning transaction processing system may be applied; however, not all transaction process flows necessarily follow the process shown in FIGS. 5A and 5B, and process flows may vary between implementations, systems, and over time. The exemplary transaction process flows 500 and 550 reflect two possible cases: a first case represented by transaction process flow 500 in which the transaction is approved, and a second case represented by transaction process flow 550 in which the transaction is rejected. Each transaction process flow 500, 550 involves the same set of five interacting systems and devices: a POS or user device 502, a commerce 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 comprise one of the client devices 110, the commerce system 504 may comprise a commerce server 130, the payment processor system 506 may comprise a payment processor server 140, and the machine learning system 508 may comprise an implementation of machine learning systems 160, 210, and / or 402. The issuing bank system 510 may comprise one or more server devices that perform transaction functions on behalf of the issuing bank. The five interacting systems and devices 502-510 may be communicatively coupled by one or more internal or external communication channels, such as network 120. In some cases, some of these systems may be combined, for example, the issuing bank may also act as a payment processor, so that systems 506 and 510 may be implemented together in a common system.In other cases, a similar process flow may be performed specifically for a merchant (e.g., without involving a payment processor or issuing bank), in which case the machine learning system 508 may communicate directly with the commerce system 504. In these variations, the general functional transaction process flow may remain similar to that described below.

[0045] The transaction process flows in both Figures 5A and 5B include several common (i.e., shared) processes 512-528. In block 512, the POS or user device 502 initiates the transaction. In the case of a POS device, this may include a cashier using a front-end device to attempt to make an electronic payment, and in the case of a user device 502, this may include a user making an online purchase (e.g., clicking "Done" in an online basket) using a credit or debit card or online payment account. In block 514, payment details are received as electronic data by the commerce system 504. In block 516, the transaction is processed by the commerce system 504, and a request is made to the payment processor system 506 to authorize the payment. In block 518, the payment processor system 506 receives a request from the commerce system 504. The request may be made over a proprietary communication channel or as a secure request over a public network (e.g., an HTTPS request over the Internet). The payment processor system 506 then makes a request to the machine learning system 508 for a score or probability for use in processing the transaction. Block 518 may additionally comprise retrieving auxiliary data for combination 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 have access to a data storage device that stores auxiliary data (e.g., similar to the configuration of FIGS. 2A and 2B ) and thus retrieves this data as part of its internal operations (e.g., based on an identifier provided within the transaction data and / or defined as part of an implemented machine learning model).

[0046] Block 520 illustrates a model initialization operation that occurs before any request from the payment processor system 506. For example, the model initialization operation may comprise loading a predefined machine learning model and parameters that instantiate the predefined machine learning model. At block 522, the machine learning system 508 receives a request from the payment processor system 506 (e.g., via a data input interface such as 412 in FIG. 4). At block 522, the machine learning system 508 may perform any predefined preprocessing before applying the machine learning model initialized at block 520. For example, if the transaction data remains character data, such as a merchant identified by a string of characters or a character transaction description, this may be converted into suitable structured numeric data (e.g., by converting character categorical data to an identifier via a lookup operation or other mapping and / or by mapping characters or groups of characters to a vector embedding). Then, at block 524, the machine learning system 506 applies the instantiated machine learning model, feeding the input data derived from the received request to the model. This may comprise applying the machine learning model platform 414 as described with reference to FIG. 4. At block 526, a scalar output is generated by the instantiated machine learning model, which may be processed in the machine learning system 508 to determine a binary "approve" or "reject" decision, or, if preferred, returned to the payment processor system 506 in response to the request made at block 518.

[0047] In 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 shows a process in which a transaction is approved based on the output of the machine learning system 508, and Figure 5B shows a process in which a transaction is denied based on the output of the machine learning system 508. In Figure 5A, the transaction is approved in block 528. Then, in block 530, a request is made to the issuing bank system 532. In block 534, the issuing bank system 532 approves or denies the request. For example, the issuing bank system 532 may approve the request if the end user or cardholder has sufficient funds and authorization to cover the transaction costs. In some cases, the issuing bank system 532 may apply a second level of security, although this may not be required if the issuing bank relies on anomaly detection performed by the payment processor using the machine learning system 508. In block 536, authorization from the issuing bank system 510 is returned to the payment processor system 506, which sends a response in block 538 to the merchant system 504, which responds to the POS or user device 502 in block 540. If the issuing bank system 510 approves the transaction in block 534, the transaction may be completed and a positive response returned to the POS or user device 502 via the merchant system 504. The end user may encounter this as an "authorized" message on the screen of the POS or user device 502. The merchant system 504 may then complete the purchase (e.g., may initiate internal processing to fulfill the purchase).

[0048] At a later point in time, one or more of the commerce system 504 and the machine learning system 508 may save data related to the transaction, e.g., as part of the transaction data 146, 240, or 300 in the previous example. This is indicated by dashed blocks 542 and 544. The transaction data may be saved along with one or more of 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., 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 FIGS. 8 and 10). The saved data may also be accessed as part of a future iteration of block 524 and may, for example, form part of future auxiliary data. In some cases, the final outcome or outcome of the transaction may not be known at the time of the transaction. For example, a transaction may only be labeled as anomalous through later review by analysts and / or automated systems, or based on feedback from a user (e.g., when a user reports fraudulent activity or indicates that a payment card or account has been compromised since some date). In these cases, ground truth labels for purposes of training the machine learning system 508 may be collected over time following the transaction itself.

[0049] Referring now to the alternative process flow of FIG. 5B , in this case, one or more of the machine learning system 508 and the payment processor system 506 reject the transaction based on the output of the machine learning system 508. For example, if the scalar output of the machine learning system 508 exceeds a retrieved threshold, the transaction may be rejected. 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 completing and returns an appropriate response to the POS or user device 502. This response is received at block 556, and the end user or customer may be notified that their payment has been rejected, for example, via an on-screen “rejected” message. The end user or customer may be prompted to use a different payment method. While not shown in FIG. 5B , in some cases, the issuing bank system 510 may be notified that a transaction related to a particular account holder has been rejected. The issuing bank system 510 may be notified as part of the process shown in Figure 5B, or may be notified as part of a periodic (e.g., daily) update. That said, the transaction may not become part of the transaction data 146, 240, or 300 (when not approved) and may still be logged by at least the machine learning system 508, as indicated by block 544. For example, with respect to Figure 5A, the transaction data may be saved along with the output of the machine learning system 508 (e.g., scalar fraud or anomaly probability) and the final outcome of the transaction (e.g., that the transaction was rejected).

[0050] First Exemplary Configuration for a Machine Learning System Some examples described herein, such as the machine learning systems 160, 210, 402, and 508 in FIGS. 1A-1C, 2A-2B, 4, and 5A-5B, may be implemented as a modular platform that allows various machine learning models and configurations to be used to provide the transaction processing described herein. This modular platform may allow various machine learning models and configurations to be used as technology improves and / or based on the particular characteristics of the available data. Two exemplary configurations of machine learning systems are provided herein, a first configuration shown in FIGS. 6A-6C and a second configuration shown in FIG. 7. These may be used independently and separately. The first configuration in FIGS. 6A-6C illustrates a neural network architecture, while the second configuration in FIG. 7 illustrates a random forest implementation.

[0051] FIG. 6A illustrates a first exemplary configuration for a machine learning system 600. In FIG. 6A, the machine learning system 600 receives input data 601 and maps it to a scalar output 602. This general processing follows the same framework as described with reference to the previous example. The machine learning system 600 comprises a first processing stage 603 and a second processing stage 604. The first processing stage 603 is shown in more detail in FIG. 6B, and the second processing stage 604 is shown in more detail in FIG. 6C. The machine learning system 600 is applied to at least data related to the proposed transaction to generate a scalar output 602 for the proposed transaction. The scalar output 602 represents the likelihood that the proposed transaction exhibits a behavioral anomaly, e.g., that the proposed transaction embodies a pattern of actions or events that differs from an expected or typical pattern of actions or events. In some cases, the scalar output 602 represents a probability that the proposed transaction exhibits an anomaly in a sequence of actions, where the actions include at least previous transactions and may also include other interactions between the entity and one or more computer systems. The scalar output 602 may be used to complete an approval decision for the proposed transaction, for example, as described with reference to Figures 5A and 5B, and may be used to determine whether the proposed transaction should be approved or rejected.

[0052] In FIG. 6A , input data 601 comprises transaction time data 606 and transaction feature data 608. Transaction time data 606 may comprise data derived from a timestamp, such as that shown in FIG. 3B , or any other data format representing the date and / or time of a transaction. The transaction date and / or time may be set as the time the transaction was initiated at a client computing device, such as 110 or 502, or may be set as the time the request was received at machine learning system 600, similar to the time of the request as received at block 522 in FIGS. 5A and 5B . In some cases, as shown later with reference to FIG. 6C , transaction time data 606 may comprise time data for multiple transactions, such as a current 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 may be received with the request and / or retrieved from a storage device communicatively coupled to machine learning system 600. In this example, transaction time data 606 is converted into relative time data for application of one or more neural network architectures. In particular, the transaction time data 606 is converted into a set of time difference values, where the time difference values ​​represent the time difference between the current proposed transaction and each of the one or more prior transactions. For example, the time difference may comprise a normalized time difference in seconds, minutes, or hours. The time difference values ​​may be calculated by subtracting one or more timestamps of the prior transaction from the timestamp for the proposed transaction. The time difference values ​​may be normalized by dividing by a maximum predetermined time difference and / or clipping at the maximum time difference value. In some cases, the one or more prior transactions may be selected from a predetermined time range (e.g., set 320 in FIG. 3A ) and / or a predetermined number of transactions.This predetermined time range and / or maximum time difference for a predetermined number of transactions may be used to normalize the time difference values.

[0053] In estimation mode, the machine learning system 600 detects a set of features from input data 601 using a first processing stage 603 and a second processing stage 604. The output data from both the first processing stage 603 and the second processing stage 604 is then used to calculate a scalar value 602. In FIG. 6A , the machine learning system 600 includes a first multilayer perceptron 610. The first multilayer perceptron includes a fully connected neural network architecture that includes multiple neural network layers (e.g., 1 to 10 layers) to preprocess data for proposed transactions, at least prior to the first processing stage 603. While a multilayer perceptron is described here, in some implementations, preprocessing may be omitted (e.g., if the incoming transaction data 608 is already in a suitable format) and / or only a single layer of linear mapping may be provided. In some examples, preprocessing may be viewed as a form of “embedding” or “initial mapping” layer for the input transaction data. In some cases, one or more of the neural network layers of the first multilayer perceptron 610 may provide learned scaling and / or normalization of the incoming transaction data 608. Generally, the fully connected neural network architecture of the first multilayer perceptron 610 represents a learned first feature preprocessing stage that converts input data related to proposed transactions into feature vectors for further processing. In some cases, the fully connected neural network architecture may learn some relationships, e.g., some correlations, between elements of the transaction feature data 608 and output an efficient representation that takes these correlations into account. In some cases, the input transaction data 608 may comprise integers and / or decimal numbers, and the output of the first multilayer perceptron 610 may comprise a vector of values ​​between 0 and 1. The number of elements or units of the first multilayer perceptron 610 (i.e., the output vector size) may be set as a configurable hyperparameter. In some cases, the number of elements or units may be between 32 and 2048.

[0054] Note that the input transaction data 608 may comprise data from the proposed transaction (e.g., as received via one or more of a client device, a POS device, a merchant server device, and a payment processor server device) and data related to the proposed transaction that is not included in a data packet related to the proposed transaction. For example, as described with reference to FIGS. 1A-1C and 2A-2B, the input transaction data 608 may further comprise auxiliary data (e.g., 148 and 242), where the auxiliary data is retrieved by the machine learning system 600 (as shown in FIG. 1C) and / or by the payment processor server 140 (as shown in FIG. 1A or 1B). The exact content included in the input transaction data 608 may vary between implementations. This example is concerned with the general technical architecture for processing the transaction data, rather than the exact format of that data. Generally, when the machine learning system 600 comprises a set of neural network layers, parameters can be learned based on whatever input data configuration is desired or what input data is available. The present example concerns the engineering design of such a technical architecture to enable transaction processing at the speed and scale described herein.

[0055] In the example of FIG. 6A , transaction time data 606 and the output of a first multilayer perceptron 610 are received by a first processing stage 603. The first processing stage 603 comprises a recurrent neural network architecture 620, shown as processing layer A in FIG. 6A . The recurrent neural network architecture 620 receives the transaction time data 606 and the output of the first multilayer perceptron 610 and generates output data through a neural network mapping (e.g., one or more parameterized functions). For example, the recurrent neural network architecture 620 uses an internally maintained state to map the transaction time data 606 and the output of the first multilayer perceptron 610 into a fixed-size vector output of a predetermined size. The output of the recurrent neural network architecture 620 is then received by a second processing stage 604 and used to generate a scalar output 602. An exemplary configuration for the recurrent neural network architecture 620 is shown in FIG. 6B . Generally, the first processing stage 603 produces a specially adapted representation of irregularly spaced time data that is particularly suited to the time-series characteristics of transaction data. For example, comparison-based neural approaches to time-series processing often require regularly spaced time samples, which do not suit the asynchronous nature of payment requests. In some cases, the recurrent neural network architecture 620 may comprise a learnable function. In other cases, which may be preferred for some implementations, the recurrent neural network architecture 620 may use fixed or provided parameters to implement functions such as a time decay function. The parameters in this case may be configured based on the characteristics of the broader model and via domain knowledge. In either case, the parameters of the recurrent neural network architecture 620 may enable intelligent aggregation of features for transactions over unevenly spaced time intervals.

[0056] The second processing stage 604 of FIG. 6A comprises one or more attention neural network architectures 660. If multiple attention neural network architectures are used, there may be b architectures provided in parallel, e.g., to provide a multi-headed attention configuration, where each of the b architectures receives the same input but has different neural network parameters, allowing them to extract different sets of features from the same data. More specifically, different attention heads may focus on different time periods; for example, one attention head may focus on transactions from the past hour, while another attention head may focus on transactions from the past month. In this manner, the first attention neural network architecture receives at least the transaction time data 606 and the output data from the recurrent neural network architecture 620 and uses this to generate output data. If only one “head” is used for the second processing stage 604, this output data is passed to a second multilayer perceptron 690 for generation of the scalar value 602. When multiple "heads" are used for the second processing stage 604, the output data for each attention neural network architecture may be combined to form the output data for the second processing stage 604. In some cases, the output data for each attention neural network architecture may be at least concatenated. In a further example, the concatenated output data may be input to at least one fully connected neural network layer for dimensionality reduction. For example, this function may be provided by a second multi-layer perceptron 690. An exemplary configuration for each attention neural network architecture 660 is shown in FIG. 6C. The first multi-layer perceptron 610 and / or the second multi-layer perceptron 690 may, by way of example, comprise between 1 and 10 dense or fully connected layers (with corresponding activation functions, such as ReLU functions) depending on the implementation.Again, the number of elements or units (sometimes called channels) for the first multilayer perceptron 610 and / or the second multilayer perceptron 690 can range from 32 to 2048 and may vary between layers, e.g., decreasing from input to output.

[0057] In FIG. 6A , at least the output of the second processing stage 604, i.e., in the form of output data from one or more attention neural network architectures 660, is mapped to a scalar output 602 by a second multiplayer perceptron 690. The output data from the last of the one or more attention neural network architectures 660 may comprise a vector of a predetermined length (e.g., 1 to 1024 elements). The predetermined length may be the same length as the output of the first multilayer perceptron 610, or may be longer if multi-head attention is used (e.g., when multiple output vectors are concatenated). In some cases, the output length (i.e., size) of each attention head may be set as a separate hyperparameter. In some test configurations, the output size per attention head ranged from about 5 to about 500 elements or units. The second multiplayer perceptron 690 comprises at least a fully connected neural network architecture with multiple neural network layers for receiving output data from the second processing stage 604 and for mapping the output data to a scalar value 602. It may comprise a series of dimensionality reduction layers. The final activation function in the multiple neural network layers may comprise a sigmoid activation function for mapping the output to a range between 0 and 1. The second multiplayer perceptron 690 may be trained to extract correlations between features output by each of the multiple attention heads and to apply one or more nonlinear functions to finally output the scalar value 602.

[0058] As shown by the dashed lines in FIG. 6A , in some variations, one or more skip connections 692, 694 may be provided that bypass one or more of the first processing stage 603 and the second processing stage 604, respectively. The first skip connection 692 bypasses the first processing stage 603, and the second skip connection bypasses the second processing stage 604. Skip connections such as these may improve training (e.g., by allowing gradients to bypass each layer, thus avoiding the “vanishing gradient” problem). They may also improve accuracy by allowing later layers to operate on correlations between earlier inputs and outputs of intermediate layers (e.g., there may be some cases in which a simple mapping between features output by the first multilayer perceptron 610 and one of the attention layers 660 can be used by the second multilayer perceptron 690 to make “better” decisions than the output of the attention layer 660 alone).

[0059] The output of the first multilayer perceptron 610, which may in some cases be considered a normalized transaction data feature vector, may be concatenated or otherwise combined with the output data of the recurrent neural network architecture 620 to provide input to one or more attention neural network architectures 660. In some cases, the first skip connection 692 may comprise a residual connection. Similarly, the output of the first multilayer perceptron 610, which may in some cases be considered a normalized transaction data feature vector, may be concatenated or otherwise combined with the output data of one or more attention neural network architectures 660 to provide input to the second multilayer perceptron 690. In some cases, the second skip connection 694 may comprise a residual connection. 6A , a first skip connection 692 around the first processing stage 603 (i.e., Layer A) and a second skip connection 694 around the second processing stage 604 (i.e., Layer B) are illustrated using dashed lines; if both skip connections 692, 694 are provided, there are effectively skip connections around both the first processing stage 603 and the second processing stage 604 (i.e., Layer A and Layer B combined). Residual connections may improve the ease with which neural network layers learn mapping functions. Whether skip connections are used and whether they are connected via concatenation, addition, or another operator (e.g., subtraction or multiplication) may be set as hyperparameters in configuration data for the machine learning system 600 and may be set based on experimentation for a particular implementation.

[0060] The configuration of FIG. 6A has been found to be particularly beneficial for high-speed inference on input transaction data, required for sub-second transaction processing. For example, modern deep learning standards dictate a small number of layers in the overall network architecture, which contributes to low latency when performing inference on raw transaction data. The first multilayer perceptron 610 is advantageously configured to preprocess transaction data, e.g., using learnable parameters, so that they are provided in a form that enables high accuracy for the remaining configuration and facilitates stable training of the configuration. The use of relative time differences between current and prior transactions allows time information to be quantified in a format usable by the configuration to determine scalar outputs and allows time to be represented in an efficient manner that does not rely on absolute timestamp values ​​(which may be large or unwieldy). Moreover, reliance on absolute timestamp values ​​may lead to a lack of generalizability across entities and / or time periods, which may lead to poor performance of the machine learning model. The first processing stage 620 is configured to process the transaction feature vector statefully output by the first multilayer perceptron 610, where the use of previous states is determined through parameters that operate on time difference data regarding the proposed transaction; for example, the recurrent neural network architecture 620 is configured to use previous transaction data (e.g., how "remembered" or "forgotten") based on the time gap between the proposed transaction and previous transactions, where the previous transaction data is an aggregated function of the transaction feature vectors for multiple previous transactions. Thus, the first processing stage 603 has a potentially infinite range regarding previous transactions and is configured to extract features based on this range.In particular, the recurrent neural network architecture 620 is only “aware” of previous transactions for the same entity via the previous state vector for that entity (indicated by the input from the previous iteration 622 in FIG. 6B ). The state vector has a fixed size, and the exact size comprises the hyperparameters of the model (e.g., it may be in the range of 4 to 128 elements). Thus, the recurrent neural network architecture 620 must summarize the past behavior of any entity up to any point in time in the form of this fixed-size vector. This then contrasts with the second processing stage 604, which has access to historical events for the entity, such as all events or a subset of events based on event time. In some cases, the second processing stage 604 may have a fixed input range (e.g., a fixed number of input feature vectors that the second processing stage 604 considers), but may apply (self-)attention across that fixed input range. In some cases, the input range of the second processing stage 604 may be specified in terms of event time, e.g., an attention head may only look at events for the same entity that occurred within the past month, where the time range of each attention head is specified as a hyperparameter. In some cases, the input range of the second processing stage 604 may have no time restriction and thus incorporate all historical events for the same entity. Any configuration chosen may depend on the average number of event data items available per entity and / or any processing resource constraints (e.g., a time-restricted attention head may be faster or easier to implement).

[0061] The first processing stage 603 and the second processing stage 604 thus apply differentiated yet complementary processing that allows information to be extracted for the determination of the scalar value 602. The second processing stage 604 applies neural attention in an efficient manner that enables fast inference on a large scale. Indeed, to address the scale of parallelized transaction processing (e.g., milliseconds for inference as shown in FIG. 6A and parallelizable to manage 1000-2000 transactions per second on a server computing device), the neural network architectures of both the first processing stage 603 and the second processing stage 604 are configured for fast computation. For example, both the first processing stage 603 and the second processing stage 604 omit some components used in comparison-based neural network architectures, yet still enable accurate inference.

[0062] An exemplary configuration for a recurrent neural network architecture 620 of the first processing stage 603 is shown in FIG. 6B. The recurrent neural network architecture 620 comprises three input interfaces for receiving input data: a time difference interface 606 for receiving data usable to output the time difference between the proposed transaction and the prior transaction; a transaction data input interface 618 for receiving data for the proposed transaction; and a state input interface 622 for receiving state data for the previous iteration. These interfaces may comprise passive interfaces, e.g., method APIs that receive data via referenced memory locations, and / or active interfaces, e.g., that apply preprocessing (e.g., calculating the time difference based on absolute time data) if preprocessing has not already been applied. Functionally, the operation is the same. The time difference interface 606 outputs a time interval Δt , which comprises data representing the time interval between the current proposed transaction i and the previous or prior transaction i−1. i,i-1may be received (or calculated based on received time data), where i represents the iteration index for the recurrent neural network architecture 620. i,i-1 The exact form of may vary between implementations. Although the interval between the i-th transaction and the i-1-th transaction is shown, in some cases a different interval between the i-th transaction and the j-th transaction (where i>j) may be used, e.g., with appropriate fetching of state for the j-th transaction. i,i-1 606 may be represented as one or more of an integer value in seconds since the Unix epoch, a floating point value representing a decimal duration in hours, a vector of seconds, minutes, hours, days, months, years, where each element is an integer value or a normalized value between 0 and 1, or a time difference embedding from an embedding layer. In the preferred case, the time interval Δt i,i-1 606 may comprise a scalar float (i.e., floating point) value representing the number of seconds elapsed between a previous transaction and the proposed transaction for the same entity. Alternatively, the time difference interface 606 may receive timestamp data for the proposed transaction and the prior transaction, and the time interval Δt i,i-1 The transaction data interface 618 may, for example, receive a transaction feature vector (i.e., a fixed-length vector) as output by the first multilayer perceptron 610, with each element having a normalized value between 0 and 1.

[0063] Recurrent neural network architecture 620 has a stored state that may be retrieved from a memory or a communicatively coupled storage device. Recurrent neural network architecture 620 receives state data from a previous iteration (e.g., i-1) at state input interface 622 and outputs state data for a current iteration (e.g., i) at state output interface 624. The state data received at state input interface 622 is retrieved following a previous application of recurrent neural network architecture 620 to data for a set of previous transactions, including prior transactions. Generally, recurrent neural network architecture 620 is configured to operate on one event (e.g., one transaction or transaction-related event) at a time (i.e., per iteration), and FIG. 6B shows the schematic processing as defined for a single event for a common (i.e., same) entity (although computations may be vectorized and / or parallelized across multiple events and / or entities for efficiency). The recurrent neural network architecture 620 of Figure 6B thus comprises a processing layer that computes [current_output, new_state] from [current_input, previous_state], where each of those data items may comprise a fixed-length vector representation. The fact that the current output (e.g., 630) depends not only on the input for the current event but also on inputs from a set of historical events for the same entity is a property of the recursive nature of the layer (e.g., each current output depends on the previous state, which in turn depends on the previous state, and so on).

[0064] The recurrent neural network architecture 620 includes a forget gate 626 for modifying state data for a previous iteration based on data output by the time difference input interface 606. For example, the time difference interface 606 may be configured to i,i-1(i.e., data representing the time difference between the proposed transaction and the prior transaction), which is used as an input to forget gate 626. Within forget gate 622, the time interval Δt i,i-1 The data representing the time difference is coded as φ d 628 is applied. d 628 may implement a parameterized function such as a time decay function. In some cases, the time difference encoding φ d 628 is of the form f(s) = [e (-s / w_1) , e (-s / w_2) ,..., e (-s / w_d) ] may be applied as a vectorized exponential time decay function, i.e., as a series of parameterized time decay calculations using [w_1, w_2...w_d] with a set of weights representing the "decay length" in seconds, where d is the size of the recursive state vector. In this case, Δt i,i-1 is passed to the function as s to output a vector of length d, and may be passed, for example, as a scalar float value representing the number of seconds elapsed between a previous event (e.g., a transaction) and the current event (e.g., a proposed transaction) for the same entity. d 628 is the time interval Δt i,i-1 The time difference encoding φ may comprise a weighting vector or matrix used to transform the representation of d628 may be a fixed (e.g., manually configurable) parameter and / or may comprise a trainable parameter of the recurrent neural network architecture 620. In the exponential case, the decay length may comprise (or be trained to) a mixture of different values ​​representing decays from minutes to weeks, such that both short-term and long-term behavior is captured. The activation vector is then used to weight the state data received at the state input interface 622 to output a modified state vector. In FIG. 6B , the activation vector is applied to the state data for the previous iteration using element-wise multiplication 632 (e.g., a Hadamard product is calculated). In this example, the state data comprises a vector that is the same length as the transaction feature vector output by the transaction data input interface 618 (i.e., the same length as the output of the first multilayer perceptron 610). The forget gate 626 effectively controls how much of the state data from the previous iteration is remembered and how much is forgotten. The configuration shown in Figure 6B is purposefully configured to allow for tractable training and fast estimation for the current transaction process context, and omits some other gates that are provided in comparison-based implementations, such as input gates or output gates.

[0065] Following modification via forget gate 626, the modified state data is combined with the transaction feature vector output by transaction data input interface 618 via combinational logic 634 to generate output data 630 for the proposed transaction (and current iteration i). Combinatorial logic 634 may perform element-wise addition (i.e., ordinary vector addition). Output data 630 also forms the output for state output interface 624. The output of state output interface 624 may then be cached or otherwise stored in memory until the next transaction.

[0066] In a preferred implementation, the state data used by the recurrent neural network architecture 620 is entity-dependent, i.e., unique to, a particular user, account holder, or merchant account. In this manner, appropriate entities may be identified as part of transaction data preprocessing, and the machine learning system 600 may be configured for those entities. In some cases, the machine learning system 600 may apply the same parameters for the neural network architecture for each entity, but may store the state data separately and retrieve only historical transaction data and / or auxiliary data associated with (e.g., indexed by) that entity. Thus, the machine learning system 600 may include an entity state store, e.g., as described with reference to FIGS. 2A and 2B, whereby data for different entities may be effectively partitioned. In other cases, parameters for the forget gate 626 may be shared across multiple entities. This may be advantageous to reduce the number of learnable parameters per entity for the overall machine learning system. For example, the exponential time decay weights described above may be fixed and shared across multiple entities, while the state data may be specific to each entity.

[0067] FIG. 6C illustrates an exemplary configuration for the second processing stage 604. FIG. 6C illustrates an exemplary attention neural network architecture 660 that may form one “head” of an attention configuration having one or more “heads.” In FIG. 6C, the attention neural network architecture 660 receives input from the first processing stage 603, where the input relates to a current event and a set of previous events for the same entity. Each “head” of the attention configuration may receive the same input data but may have different parameter data, thereby allowing each “head” to learn a different set of parameters. Because the attention neural network architecture 660 determines what portions of the input to attend to based, in part, on the input, the exemplary configuration of FIG. 6C may be referred to as a self-attention architecture. In the exemplary configuration of FIG. 6C, an input feature vector is generated based, at least in part, on the previous iteration output from the first processing stage 603 and is weighted based on the current iteration output for the first processing stage 603. The input feature vector is also generated based on data representing time differences, such that the time interval between the proposed transaction and one or more prior transactions can affect the weights applied. In practice, this provides differential weighting based on how irregularly spaced the time data is. Generally, the attention neural network architecture 660 comprises a neural network layer for applying attention weights to the input feature vector to generate output data for the attention neural network architecture 660. The attention weights are calculated based on the input feature vector and current output data from the first processing stage 603. This is described in more detail below.

[0068] 6C, the attention neural network architecture includes a time difference interface 662, a history input interface 664, and a current input interface 666. The time difference interface 662 is similar to the time difference interface 606 of the recurrent neural network architecture 620, but in this case, the relative time interval Δt i,i-1 , ..., Δt i,1 , i.e., a vector of multiple time differences between the current proposed transaction and (each of) a set of historical or prior transactions. For example, this may be a concatenated multiple time interval values, where each time interval value is in a format similar to that output by time difference interface 606. Time difference interface 662 may receive the time data as this vector of relative time intervals, or may receive absolute time data and calculate the relative time intervals based on this absolute time data. In a preferred example, time difference interface 662 receives time difference data comprising at least the time difference as received by time difference input interface 606 and data representing one or more time differences between the proposed transaction and one or more further prior transactions. History input interface 664 receives history output data from first processing stage 603. For example, this may comprise the output of recurrent neural network architecture 620, buffered for a predetermined period of time or number of iterations.

[0069] In some cases, both the history input interface 664 and the time lag interface 662 output data for calculations related to a fixed or predetermined number of previous iterations (i-1 in this example, referred to as T below). Or, in other words, the history input interface 664 and the time lag interface 662 can be configured to output data for calculations related to a subset of historical events. That subset may be constrained based on a limited number of events (e.g., the last 10 events for an entity), a configured time period (e.g., the past month for the same entity), or both (e.g., events in the past month capped at the last 10 events). This is preferable for managing data size constraints and computational tractability. However, if some transactions are small, the number of previous iterations may expand with each iteration.

[0070] Finally, current input interface 666 receives current output data from first processing stage 603. In the case of attention neural network architecture 660 shown in Figure 6C, this is at least the output data from recurrent neural network architecture 620 for the current iteration (i.e., output data 630 in Figure 6B). In some cases, for example, when skip connections such as those indicated by dashed lines in Figure 6A are used, current input interface 666 may receive a combination of output from first processing stage 603 (e.g., output data from recurrent neural network architecture 620) and input for first processing stage 604 (e.g., input transaction data 618 received as shown in Figure 6B).

[0071] In the example of FIG. 6C, the time difference data received from the time difference interface 662 is encoded as time difference φ e 668. The time difference encoding φ in FIG. d 628, time-difference encoding φ e668 may comprise a parameterization function that is applied to the time difference data. e The parameters for 668 may be fixed or trainable (i.e., learned) depending on the implementation. In some implementations, the time difference encoding φ e 668 is the time difference coding φ in FIG. 6B d 628. In other implementations, it may comprise a fully connected neural network layer. In some cases, the time difference encoding φ e 668 may output a tensor (i.e., a matrix) comprising a collection of vectors, one vector for each event time difference. Each vector may be calculated based on the time elapsed between a particular historical event and the current invention (e.g., the current proposed transaction). In some cases, the time difference encoding φ e Each vector in 668 corresponds to the time difference encoding φ in FIG. 6B. d 628, and this is repeated for each time difference. In other cases, various positional codings may be used, such as coding based on (weighted) sinusoidal functions. An example of a sinusoidal positional coding is given in the paper "Attention is All You Need" by Vaswani et al. (published on arXiv on December 6, 2017), which is incorporated herein by reference. The time difference coding φ e 668 may be parameterized based on a matrix of weights that may be used to implement the temporal encoding. d Regarding 628, time difference coding φ e The parameters for 668 may be fixed (eg, supplied as default configuration values) and / or may be learned via (end-to-end) training.

[0072] In this example, the time difference coding φ eThe output of 668 comprises a matrix of relative time encodings, with one encoding vector per time difference, which is received at concatenation block 670. Concatenation block 670 concatenates the relative time encodings with the historical output data from first processing stage 603, e.g., the set of buffered outputs from recurrent neural network architecture 620 for iterations i-1 through 1. For example, each vector of time encodings relating to a particular time difference may be concatenated with the vector for the corresponding encoding event. Thus, concatenation block 670 generally outputs a feature tensor that combines the time difference data and the historical output data from first processing stage 603 (e.g., if this input data is in vector form). The feature tensor is then used as input for determining key vectors and value vectors. The feature tensor may be organized as a longer flattened vector or as a multidimensional array (e.g., a buffer-like data structure with one dimension indexed by the iteration index).

[0073] The attention neural network architecture 660 in FIG. 6C may be viewed as implementing a single-headed self-attention system. The attention system uses a key vector, a query vector, and a value vector. In the example of FIG. 6C , the value vector is calculated using a value vector calculation operation 672, the key vector is calculated using a key vector calculation operation 674, and the query vector is calculated using a query vector calculation operation 676. In some cases, vectors may be calculated for each iteration to generate attention weights for that iteration. Both the value vector calculation operation 672 and the key vector calculation operation 674 receive as input the output of the concatenation block 670, i.e., receive elements of a feature vector or feature tensor calculated using time difference data and historical output data from the first processing stage 603. The terms key, query, and value are used in the art to refer to various expressions used to apply attention. For example, these terms were developed with reference to an information retrieval system in which a query is mapped against a set of keys to return one or more values ​​as matches. In neural attention, at a high level, a query vector is compared to a key vector and used to determine a set of attention weights. In some cases, one or more query vectors may be compared to multiple key vectors (e.g., via a matrix operation) to generate a set of attention weights, where each weight is associated with a different iteration index. The set of attention weights is applied to at least one value vector to provide a weighted vector output. In some cases, the weighted value vectors for each iteration are combined in an end-weighted sum to generate an output vector (such as 688). Each of the value vector calculation operation 672, key vector calculation operation 674, and query vector calculation operation 676 comprises the application of one or more sets of parameter weights (e.g., as applied via one or more neural network layers), where the parameter weights are learnable parameters of the attention neural network architecture 660.Thus, attention neural network architecture 660 “learns” how to transform the input feature tensors output by concatenation block 670 to generate appropriate key vectors and value vectors, and how to transform the current output data from first processing stage 603 to generate an appropriate query vector. In effect, the query vector calculated by query vector calculation operation 676 represents how the current output of recurrent neural network architecture 620 should be represented in order to look for information in the input feature vector (i.e., the time difference data and previous outputs of recurrent neural network architecture 620) that should be used to weight the input feature vector (i.e., emphasize some aspects and de-emphasize others). Because the weights used in each of value vector calculation operation 672, key vector calculation operation 674, and query vector calculation operation 676 are trainable parameters, through training, attention neural network architecture 660 learns how best to manipulate the input data to generate output data that leads to accurate scalar outputs that represent behavioral anomalies in transactions.

[0074] Referring to the mechanism for applying attention, the query vector output by the query vector calculation operation 676 is applied to the key vector output by the key vector calculation operation 672 using a first dot (i.e., scalar) product operation 678 that calculates the dot product of the key vector and the query vector. This may be performed for a set of multiple key vectors and / or multiple query vectors to output the dot product result for each iteration in the historical data. In parallel, a further time-staggered encoding φ w 680 is applied to the time difference data output by the time difference interface 662. The time difference encoding φ w 680 is the time difference coding φ d 628 and time-difference coding φ e 628. In some cases, the time difference encoding φw 680 outputs one value for each (historical event, current event) pair for the same entity, which is a function of the time elapsed between the historical event and the current event, e.g., Δt i,j where i is the current event and j is the historical event. w The function applied by 680 may take a variety of forms. As mentioned above, the parameters for the function may be fixed or trainable. In some cases, the parameters may be configured to assign a larger weight to events from some time intervals (e.g., events from the past week for the same entity) to encourage the attention layer to pay more attention to events from that time interval. Thus, the time difference encoding φ w Through controlling the parameters of 680, a particular attention layer can be configured to pay more or less attention to particular time intervals. If the parameters are defined as configuration parameters, this may allow the operator to control the behavior of the attention layer, and if the parameters are learned during training of the neural network architecture, the parameters may converge to values ​​that increase successful classification of anomalies.

[0075] Time difference encoding φ w The output of applying 680 is then combined in combination logic 682 with the dot product output by the first dot product operation 678. In operation 682, a time-based weight for (historical event, current event) is added to the dot product between (query vector for current event, key vector for historical event), which may be a scalar. The combination logic 682 effectively adjusts the initial set of attention weights calculated using the key vector and query vector with the weighted time difference data. The time difference encoding φ wThe weighting of the time difference data output by the time difference interface 662 via 680 is important because it allows the attention weights to be adjusted to encourage the attention neural network architecture 660 to pay more attention to some samples within some time intervals than others. For example, it has been found in some testing that this adjustment often emphasizes transaction data features within a learned time range, such as around one week from the proposed transaction.

[0076] Finally, to complete the calculation of attention weights from the input feature tensor and the current output data from the first processing stage, a softmax operation 684 is applied, and a second dot product operation 686 calculates the dot (i.e., scalar) product of the output of the softmax operation 684 and one or more value vectors output by the value vector calculation operation 672. The second dot product operation 686 effectively applies the normalized attention weights output by the softmax operation 684 to the one or more value vectors to provide output data 688 for the attention neural network architecture 660. The softmax operation 684 applies a softmax, or normalized exponential function, to output a set of normalized attention weights, which may be viewed as a set of probabilities (i.e., they sum to 1 and each lie in the interval 0 to 1). The second dot product operation 686 then calculates a weighted sum of iterations of the input feature tensor, weighted by the calculated attention weights.

[0077] For example, the output of a recurrent neural network architecture is a vector A of length L for each iteration j. j The time difference between the current iteration i and the previous iteration j (where i ≠ j) can be expressed as Δt i,j This time difference may be a scalar floating-point value. In operation, the recurrent neural network architecture generates a vector A representing the previous state (e.g., j=i−1). i-jand time-difference encoding φ d The time difference is encoded using φ d If is a vector of parameters, e.g., a set of time-decay weights of length K, then the forget gate 626 determines f i (φ d ,Δt i,j ) is first computed, and then · is an element-wise multiplication of the modified state S i S i = f i (φ d ,Δt i,j )·A j As well as X i is the input transaction data feature vector for iteration i, also of length K (e.g., as output by the first multilayer perceptron 610), and i = S i + X i Referring now to the attention neural network architecture 660, the time difference interface 662 calculates Δt for T time differences, i.e., j = i-1 to iT. i,j If each time difference is a signed-point scalar as above, the input to time difference interface 662 may receive a vector Δ of size T. i Similarly, the history input interface 664 may receive the buffered outputs (for j = i-1 to iT) A of the recurrent neural network architecture. j A multidimensional array H of size K × T representing i The current input interface 666 may then receive A for the current iteration. i The time difference encoding φ e 668 is a parameterized function f e (φ e ,Δ i ) may be similarly performed, except that φ e is a set of parameters for time difference encoding. This function is a vector for each time difference, i.e., a multidimensional array (or matrix) E i, or size M×T, where M is the length of the time difference encoding. A concatenation operation 670 may then stack corresponding ones of the T vectors from each source to output a (K+M)×T matrix. A value calculation operation 672 and a key calculation operation 674 may generate a value vector and a key vector, respectively, for each of the T samples that form the input (i.e., the concatenated T time intervals and buffered output). In a first dot product operation 678, a dot product of the query vector and each of the T key vectors may be calculated to generate T initial attention weights. The time difference encoding φ w 680 may apply a matrix of parameter size T×T to the parameterized function f w (φ w ,Δ i ) followed by the application of a weighted time vector D of length T i (i.e., D i = fw(φ w ,Δ i )), weighted time vector D i is then added to the vector of T initial attention weights in combinational logic 682, i.e.,

[0078]

number

[0079] As explained above, the time difference coding φ w There is a scalar time-based weight from 680 and a scalar key query dot product weight, which are added (combined) together in component 682. A softmax function is then applied in softmax operation 684,

[0080]

number

[0081] A vector of T attention weights

[0082]

number

[0083] may then be used to weight each of the T value vectors output by the value vector calculation operation 674, and the output B i but,

[0084]

number

[0085] may be generated as

[0086]

number

[0087] is one of the T attention weight values, and V i,j is the corresponding value vector. The resulting output vector B i is then the same length as the value vector (which can be M+K) or a customizable length set by matrix multiplication in the value vector calculation operation 672.

[0088] The second processing stage 604, using one or more attention neural network architectures 660 as described above, allows a sequence of actions or events related to the proposed transaction, which may be data received with the transaction request and / or auxiliary data, to be evaluated and weighted, and the relative times of the various actions that make up the features may be used as part of the weighting. In some examples, the input transaction features 608 may also include a sequence of measured user inputs, such as mouse clicks, and / or other actions related to the user, such as changes to account history. This allows the output scalar value to be sensitive to patterns in the input data. For example, two transaction requests within a few seconds may be associated with a different detected pattern than two transaction requests within a few days.

[0089] The architecture of the first exemplary configuration, as shown in Figures 6A-6C, thus provides advantages over comparison-based transaction processing methods and systems that do not allow the above-described patterns in sequences of data to be detected. Specifically, the first exemplary configuration, as shown in Figures 6A-6C, provides accuracy improvements, such as reducing false positives and increasing true positives, avoiding errors and suboptimal results traditionally found when attempting to apply machine learning within the context described herein. For example, the machine learning architecture described above can identify sequences of asynchronous actions over time with appropriate recognition of the time intervals and time density of different types of individual actions, and can make inferences therefrom. By using stateful processing in the first processing stage 603 and an adaptive attention mechanism in the second processing stage 604, the first exemplary configuration can learn useful functions established by the long-term trends of entities (such as users or merchants).

[0090] 6A operate synergistically together, in some examples, each of them can be implemented separately, e.g., with or without one or more of the first multilayer perceptron 610 and the second multilayer perceptron 690. For example, in some implementations, the second processing stage 604 may be omitted, such that the second multilayer perceptron 690 operates solely on the output of the first processing stage 603, or the first processing stage 603 may be omitted, such that the second processing stage 604 operates solely on the feature vectors (e.g., A for one or more of the current data and historical data) output by the first multilayer perceptron 610. i Not X i ) is received.

[0091] In some cases, the forget gate 626 may be implemented as a form of time decay processing, where the neural network cells (i.e., the recurrent neural network architecture 620) have local memory (i.e., state) that is time decayed before processing a new data sample. d 628 may, in some examples, comprise one or more exponential time decay coefficients.

[0092] The first processing stage 603 may be viewed as computing a weighted sum of the new input against the prior input. The forget gate 626 acts as a form of time decay to adjust the contribution of past transactions to the sum. The time decay may be purely a function of time, since a pair of transactions may be considered to occur independently of anything that happened in the intervening period. As a result, the first processing stage 603 provides long-term memory for the contribution of prior transactions that are not the most recent transaction.

[0093] As explained above, in some implementations, (φ d 628, φ e 668, and φ w680) is a time-difference encoding method for a time interval f i (φ i ,Δt i,j ), where φ i is a set of parameters. At least in the forget gate 626 implementation, f(Δt i,i-a ) * f(Δt i,i-b ) = f(Δt i,i-a +Δt i,i-b ) The function may be constrained, for example, to comprise an exponential function. In some cases, weighting may be applied, followed by an exponential activation function. In this case, the contribution of an iteration depends only on the gap between iterations and is independent of any intermediate iterations.

[0094] For example, in the above variation, consider a case involving three events or actions, e.g., involving three transactions: a first event (A) occurs at midnight, a second event (B) occurs at 3:00 AM (i.e., three hours after event A), and a third event (C) occurs at 9:00 AM (i.e., six hours after event B and nine hours after event A). The recurrent neural network architecture can determine a previous state S based on the interval between the previous event (i-1) and the current event (i). i-1 to current state S i and then apply it to the input X for the current event. i In this case, for every update, the recurrent neural network architecture maintains the state S i = X i + f(t i -t i-1 ).S i-1 For three events, various states are calculated as S A = X A +0, S B = X B + f(3 hours).S A , and S C = X C + f(6h).S Bcan be calculated as, C = X C + f(6 hours).X B + f(6 hours).f(3 hours).X A For example, if the function applies exponential time decay, then f(Δt i,i-a )* f(Δt i,i-b ) = f(Δt i,i-a +Δt i,i-b ), then S C = X C + f(6 hours).X B + f(9 hours).X A , i.e., a state is a weighted linear combination of previous states, where each contribution may be determined independently.

[0095] In some cases, the forget gate 626 may apply exponential time decay with one or more constant decay rates or coefficients (possibly multiple such coefficients). These decay rates or coefficients may be set as hyperparameters of the recurrent neural network architecture 620 or may be learned. In some examples, exponential time decay can ensure that the contribution of past actions to the state of the recurrent neural network architecture depends solely on the time elapsed since a more recent event took place. In other words, the time elapsed between events due to an entity using this variation may be independent of any other actions performed in the intervening time. The use of time decay in the recurrent neural network architecture 620 also allows for long-term memory storage, where the duration of long-term memory storage may be set, for example, by a half-life parameter of the exponential time decay. In such cases, a function implementing a range of half-lives may be used, which facilitates the encoding of action patterns and varies over different time periods.

[0096] In some cases, all temporal encodings may use fixed (i.e., retrieved or supplied) parameter values ​​(e.g., set as configuration data) rather than learned parameters. In this case, all transformations and / or aggregations of historical and current feature vectors with respect to time differences may be "imposed" on the architecture. This may increase the controllability of the system and may facilitate (and even guide) the training of learnable parameters for attention heads and / or multilayer perceptrons. For example, by setting values ​​for exponential time decay for different time periods, learned features that can be mapped to these different time periods produce useful temporal difference encodings that provide a foothold for the machine learning systems described herein. Furthermore, non-learnable parameters increase the speed of processing and training, which is particularly suited to high-speed, high-volume transaction processing.

[0097] Second Exemplary Configuration for a Machine Learning System 6A-6C above illustrate one possible configuration for a machine learning system. A second alternative configuration 700 is illustrated in FIG. 7. The first and second configurations are not limiting, and some examples described herein may be performed using different machine learning models than both the first and second configurations, e.g., other neural network architectures and / or Bayesian configurations. Like the first exemplary configuration 600, the second exemplary configuration 700 may be used to implement one or more of the machine learning systems 160, 210, 402, and 508 (where that configuration may comprise an implementation loaded by the machine learning model platform 414) in FIGS. 1A-1C, 2A-2B, 4, and 5A-5B.

[0098] The second configuration 700 of Figure 7 is based on a random forest model. The random forest model is applied to an input feature vector 710 and comprises multiple decision trees 720 applied in parallel. Each decision tree 722, 724, 726 produces a different classification value C i7, three decision trees 722, 724, and 726 and three classification values ​​732, 734, and 736 are shown, but there may be a total of N decision trees, where N is a configuration parameter and may reach hundreds. The classification values ​​730 are passed to an ensemble processor 740, which combines the classification values ​​730 from each of the decision trees 720 to generate a final scalar output 750. The ensemble processor 740 may calculate a weighted output of the decisions of each decision tree 720 and / or apply a voting procedure.

[0099] Training machine learning systems to process transactional data In some examples, machine learning systems such as those described herein may be trained using labeled training data. For example, a training set may be provided that comprises data related to transactions that have been labeled as “normal” or “fraudulent.” In some cases, these labels may be assigned based on reported fraudulent activity, i.e., using past reports of fraudulent activity. For example, data related to transactions that have been approved and processed without subsequent reports of fraudulent activity may be labeled as “0” or “normal,” while data related to transactions that have been rejected and / or that have been later reported as fraudulent and otherwise marked or blocked may be labeled as “1” or anomalous. An example of this method of training is described with reference to FIG. 8.

[0100] In another example described herein, an improved pipeline for training a machine learning system is presented. This improved pipeline enables training of a machine learning system, such as the one described herein, adapted to process transaction data. Training the pipeline enables the generation of synthetic data samples for training. This is particularly useful when attempting to train a machine learning system for classification of anomalies in transactions (e.g., representing fraud or other malicious activity), since there are typically few examples of “unexpected” action patterns that allow for a balanced set of ground truth training labels. The improved pipeline for training a machine learning system involves adapting a feature vector generation process before applying the machine learning system, and adapting the training procedure. In the following sections, the adaptation to the feature vector generation process is first described, followed by the training itself. An example of this method of training is described with reference to Figures 9-13.

[0101] Pre-labeled training example 8 shows an example 800 of training a machine learning system for transaction processing using a pre-labeled training set. This method may be used for cases where a large body of labeled training data is available. However, this method may have limitations, and improved methods of training for transaction processing are described below with reference to FIGS. 9-13.

[0102] In example 800 of FIG. 8 , training data 810 is obtained. The training data 810 comprises feature data 812, which may be feature values ​​organized as a numerical tensor, and labels 814, which in this case are either a value of “0” representing transactions associated with a normal pattern of action or a value of “1” representing transactions associated with an anomalous or fraudulent pattern of action. In training mode, the feature data 812 is provided to a machine learning system 840 for output of a classification 850, which preferably comprises a scalar output. The machine learning system 840 is parameterized with a set of parameters 842, which may be initialized to a set of random values. During use, a training engine 860 receives the output of the machine learning system 840 for a particular set of feature data and compares it to the label for that set of feature data. The training engine 860 may evaluate a loss function, such as a logistic-logarithmic loss function, that calculates the error between the prediction and the label. This error is then used to adjust the parameters 842.

[0103] 6A-6C, parameters 842 may comprise neural network weights (and possibly biases, although these may be incorporated into the weights) associated with one or more of components 628, 668, 672, 674, 676, and 680. In this case, feature data 812 may comprise both current transactions associated with labels, but also state data for recurrent neural network architecture 620, time difference data, and historical data used to generate inputs for attention neural network architecture 660.

[0104] In some cases, training and / or validation of the machine learning system 840 may be performed using externally labeled data. This may be difficult to obtain, but may arise, for example, from a data feed of transaction “chargeback” information that indicates which transactions were refunded (as this may indicate that the transaction was fraudulent or anomalous). In some cases, correlation operations may be performed to relate the transaction chargeback information to transactions that have been disputed by the user (e.g., a chargeback may be due to a defective product rather than fraud). Feedback on the output may enable the machine learning system to operate adaptively and self-correct for model drift over time.

[0105] Feature Vector Generation FIG. 9 illustrates an example machine learning system 900 with adaptations to enable training based on unlabeled data. In FIG. 9, the example machine learning system 900 generates a feature vector based on observable features and contextual features. The machine learning system 900 includes an observable feature generator 910 and a contextual feature generator 930, each configured to generate a different portion of the feature vector 930, which is provided as input to a trained binary classifier 940. The binary classifier 940 is trained to map the input feature vector 930 to a scalar output 950, which indicates the presence of an anomaly. For example, the binary classifier 940 may be trained on data with two assignable labels. In some cases, these labels may be “0” and “1,” where “0” represents no anomaly and “1” represents the presence of an anomaly. In this case, the binary classifier 940 may output a value between 0 and 1, representing the probability that an anomaly exists. The binary classifier 940 is parameterized using a set of parameters 942. For example, these may comprise weights for a neural network architecture and / or branch weights for a decision tree or random forest model. These parameters may be "learned" through training methods described in more detail below. The scalar output 950 of the binary classifier 940 may be used to process the current transaction or a proposed transaction.

[0106] 9 , an observable feature generator 910 receives transaction data 912, 914 and uses it to generate an observable feature vector 916. A context feature generator 930 receives auxiliary data 922, 924 and uses it to generate a context feature vector 926. The observable feature vector 916 and the context feature vector 926 are then combined to generate an overall feature vector 930. In some cases, the observable feature vector 916 and the context feature vector 926 may be combined by concatenating the two feature vectors 916 and 926 to generate a longer vector. In other cases, combinatorial logic and / or one or more neural network layers may be used that receive the observable feature vector 916 and the context feature vector 926 as input and map this input to the feature vector 930.

[0107] In FIG. 9, observable feature generator 910 receives two types of transaction data. A first portion of transaction data 912 comprises data related to a particular transaction being classified. For example, this may comprise a current transaction or a proposed transaction, such as those shown to be processed in FIGS. 5A and 5B. The first portion of transaction data 912 may comprise data derived from a data packet received with a request to process a proposed transaction. A second portion of transaction data 914 comprises data related to transactions within a group defined based on the proposed transaction. For example, these may comprise transactions within a defined time window. This may be defined based on a predefined (absolute) time range set relative to the timestamp of the proposed transaction, or based on a relative time range defined relative to a discrete number of transactions (e.g., the last X transactions for a particular user associated with the proposed transaction). Thus, observable feature generator 910 may be said to generate observable feature vector 916 based on recently observed data, which includes at least data derived from the proposed transaction. In comparing, the context feature generator 920 generates a context feature vector 926 based on one or more of the transaction data outside the time window and the retrieved data related to a uniquely identifiable entity for the proposed transaction. For example, FIG. 9 shows that the context feature generator 920 receives auxiliary data 922 and historical transaction data 924. The uniquely identifiable entity may be a particular end user (e.g., a cardholder) or a merchant, and the auxiliary data 922 may be data retrieved from a record associated with the uniquely identifiable entity (e.g., so-called static data that is separate from transaction data representing past transactions). The auxiliary data 922 may comprise auxiliary data 146 or 242 as previously described.The historical transaction data 924 may comprise data related to transactions that fall outside a time window, e.g., data derived from transactions that fall outside the above-mentioned predetermined time range or relative time range set with respect to the timestamp of the proposed transaction. The context feature generator 920 may be configured to calculate aggregate metrics (or retrieve pre-calculated aggregate metrics) over the historical transaction data 924 and then include the aggregate metrics in the context feature vector. The aggregate metrics may comprise simple statistical metrics or more advanced neural network-extracted features.

[0108] A pipeline for training a machine learning system FIG. 10 shows a pipeline 1000 for training a machine learning system that relies on the feature generation process of FIG. 9 . The pipeline 1000 operates on a training set 1010 of data samples 1012. In this example, the training set 1000 comprises unlabeled data, i.e., the data samples 1012 do not have labels (i.e., assigned data values) that indicate whether they relate to normal behavior or whether they relate to abnormal behavior. In other cases, some (i.e., at least a portion) of the training set may be labeled, but this may be a small percentage of the available data. The data samples may be feature vectors similar to the feature vector 930 shown in FIG. 9 . The data samples may comprise feature vectors such as those generated by the configuration of FIG. 9 and / or feature vectors that were not generated by the configuration of FIG. 9 but that represent historical input data for training the binary classifiers that form the machine learning system.

[0109] The pipeline 1000 begins with a data partitioning stage 1020, which operates on a training set 1010 and partitions data for a data sample 1012 in the training set 1010 to generate partitioned data 1030. In particular, the data partitioning stage 1020 partitions the data sample into two feature sets: a first feature set 1032 representing observable features, and a second feature set 1034 representing context features. The first feature set 1032 and the second feature set 1034 may be the observable feature vector 916 and the context feature vector 926 as described with reference to FIG. 9. If the data sample 1012 was generated as the feature vector 930 using the preprocessing of FIG. 9, the data partitioning stage 1020 may comprise partitioning the concatenated feature vector (e.g., splitting the feature vector into two predefined sets of elements). If the data sample 1012 comprises a collection of data before preprocessing, for example, similar to the input data 912, 914, 922, and / or 924, the data partitioning stage 1020 may partition the data according to data source and / or time data. In some cases, the data partitioning stage 1020 may function in a manner similar to the observable feature generator 910 and the context feature generator 920.

[0110] The first feature set 1032 may have characteristics similar to those of the observable feature vector 916 and the context feature vector 926 as described with reference to Figure 9. For example, the observable features may be derived, at least in part, from a time window of transaction data defined for the transaction associated with each data sample. The context features may be derived, at least in part, from one or more of transaction data outside the time window and retrieved data related to a uniquely identifiable entity for the transaction associated with the data sample. In Figure 10, the feature vector pair

[0111]

number

[0112] and

[0113]

number

[0114] where i represents the particular ith data sample, O represents the observable features, and C represents the context features.

[0115] Following the data partitioning stage 1020, the partitioned data sample 1030 is passed to a synthetic data generation stage 1040. During the synthetic data generation stage 1040, a set of synthetic data samples 1050 is generated. The synthetic data sample 1050 is generated by combining features from two feature sets, each relating to two different entities in the set of uniquely identifiable entities. For example, this may be performed by adding the second set of features 1034 to groups indexed by entity identifiers, then iterating through the first set of features 1032 and randomly selecting paired portions from the groups, where the entity identifiers of the selected paired portions do not match the entity identifiers of the corresponding first set of feature portions. The synthetic data sample 1050 thus comprises mixed pairs 1052, 1054 from the first and second sets of features 1032, 1034.

[0116] Following the synthetic data generation stage 1040, the original segmented data 1030 and the synthetic data samples 1050 are passed to a data labeling stage 1060. During the data labeling stage 1060, the original segmented data 1030 is assigned a label indicating the absence of anomalies. In this case, that label is the numeric value "0." The synthetic data samples 1050 are then assigned a label indicating the presence of anomalies. In this case, that label is the numeric value "1." The two sets of labeled data samples are then combined into an augmented training set 1070 comprising the labeled data. As can be seen in FIG. 10 , the augmented training set 1070 comprises pairs of observable features 1072 and context features 1074, for example, as represented by distinct sets of feature vectors or vector elements and assigned labels 1076 that can be "0" or "1." The augmented dataset 1070 may then be used to train a binary classifier implementing the machine learning system of the previous example. For example, the augmented dataset 1070 may be used to train the binary classifier 940 shown in FIG. 9 , i.e., to determine the set of parameters 942. If the binary classifier 940 comprises a neural network architecture, during training, predictions from the binary classifier 940, in the form of scalar outputs 950, may be compared among the assigned labels 1076, e.g., in a loss function, and errors based on differences between the scalar outputs 950 and one of the numeric values ​​0 or 1 in the labels may propagate back through the neural network architecture. In this case, the difference of the loss function with respect to the weights of the neural network architecture may be determined and used to update those weights, e.g., using gradient descent, i.e., one of its variations. For example, this may be used for the neural network architecture shown in FIGS. 6A-6C .If the binary classifier 940 comprises, for example, a random forest classifier as shown in FIG. 7, the augmented training set may be passed to a model “fitting” method (such as random_forest.fit(X, y) as defined in a machine learning programming library) as a set of data samples (the concatenation of portions 1072 and 1074) and a set of corresponding labels 1076.

[0117] Current training pipelines thus provide a solution to the technical problem of training an anomaly classifier on unlabeled transaction data. Rather than looking at unsupervised classifiers, which generally have poorer accuracy and require extensive calibration, the present example adapts the feature generation process to allow the problem to be reframed as a supervised learning problem. This then allows more powerful supervised learning models to be used that can identify anomalies in the transaction data that more closely match deviations from expected behavior. The present example splits the training data into two sets of features: a first set of features based on so-called observable features, i.e., data obtained from or calculated using the transaction being classified, and a second set of features based on so-called contextual features, i.e., data not obtained or calculated using the data for the transaction being classified, e.g., features derived from historical transaction data and / or lookup data related to one or more specific entities associated with the transaction being classified. Furthermore, collapsing transaction processing into a single binary classification allows this approach to be effective and still allow for a valid output, for example, to determine whether the transaction being classified should be approved or rejected.

[0118] 11A and 11B show variations on the examples of FIGS. 3A and 3B that are important to the current process of training. FIG. 11A schematically shows a set of transaction data 1100 for a uniquely identifiable entity. For example, these may include transactions over time recorded for an end user, such as a cardholder, or a particular payment account. They may also include transactions associated with a particular merchant. Transaction data 1100 may include records of approved transactions. FIG. 11A also shows data for a proposed transaction 1102. This may include received data for a proposed transaction that is yet to be approved or rejected. If the transaction is approved, the data for the proposed transaction 1102 may be added to transaction data 1100.

[0119] FIG. 11A also illustrates how observable features and contextual features may be defined with respect to transaction data 1100. Where each vertical section represents data for a different transaction, observable features may be defined as features calculated from a first set of transaction data 1110, and contextual features may be defined as features calculated from a second set of transaction data 1120. The first set of transaction data 1110 includes data for at least the proposed transaction 1102 and may be viewed as raw observations of actions or behaviors defined around the proposed transaction. Thus, observable features relate to “observations” of an entity's current or recent behaviors, as expressed through those actions, where those actions are evidenced via the transaction data 1110. The second set of transaction data 1120 does not include the proposed transaction 1102 and may be used to calculate historical metrics that are equivalent to the data for the proposed transaction 1102. The contextual features may comprise predictions of current or recent behavior based on actions or behavior as represented in the second set of transaction data 1120 .

[0120] 11B shows an example of a feature vector 1140. The feature vector 1140 may comprise the data sample 1012 from FIG. 10 or the feature vector 930 from FIG. 9. FIG. 11B shows the feature vector 1140 following a first set of preprocessing to convert the input data into numeric values. Note that further preprocessing based on either a defined range or neural network mapping may also be performed to further convert the shown numeric values ​​into normalized values ​​(e.g., floating-point values ​​between 0 and 1 or between −1 and 1). The feature vector 1140 comprises several vector elements related to different data inputs. For example, the feature vector 1140 may include an entry "amount" that specifies the amount (e.g., in local currency units) for the proposed transaction, an entry "aggregate_amount" that specifies the total amount to be spent within the first set of transaction data 1110, an entry "merchant_id" that is a unique identifier for the merchant being used for the proposed transaction, an entry "merchant_likelihood" that represents the likelihood that the user entity making the proposed transaction will use the merchant specified by the merchant identifier, an entry "total_amount" that represents an aggregate metric (e.g., sum) of transaction amounts from the second set of transaction data 1120, an entry "primary_account" that is a Boolean value indicating whether the transaction is related to the current user entity's primary account, an entry "me_amount" that represents another aggregate metric (e.g., median) of transaction amounts from the second set of transaction data 1120, and an entry "country_id" that represents the home country of the current user entity. In this case, the entries "amount," "aggregate_amount," and "merchant_id" may represent observable features, and the remaining entries may represent context features.

[0121] How to train a machine learning system FIG. 12 illustrates an example method 1200 for training a supervised machine learning system to detect anomalies in transaction data. Method 1200 may be used to implement pipeline 1000 shown in FIG. 10. At block 1202, method 1200 comprises obtaining a training set of data samples. The data samples may comprise data samples such as 1012 in FIG. 10. Each data sample is derived at least in part from transaction data and associated with one of a set of uniquely identifiable entities. For example, the data samples may have, or may be derived based on, one or more unique identifiers related to a user or merchant. In this method, at least a portion of the training set is unlabeled. For example, it may comprise a feature vector such as 1140 shown in FIG. 11B that does not have an anomaly label assigned.

[0122] At block 1204, method 1200 comprises assigning a label to unlabeled data samples in the training set that indicates the absence of anomalies. For example, such a label may be the illustrated "0" label assigned as part of label 1076 in FIG. 10. The label may comprise a numeric or binary value. Because the data samples are derived from transaction data, e.g., at least data 1100 as shown in FIG. 11A, they relate to processed transactions and are therefore assumed to represent, for example, the "normal" behavior of data expected during transaction processing.

[0123] At block 1206, the method comprises partitioning data of the data samples in the training set into two feature sets: a first feature set representing observable features and a second feature set representing contextual features. The observable features are derived from a function of at least transaction data for the current transaction, e.g., a function of at least transaction data 1102 in FIG. 11A. The contextual features are derived from one or more of a function of historical transaction data excluding the current transaction and retrieved data related to a uniquely identifiable entity for the current transaction. For example, the contextual features may be derived from data similar to data 922 and 924 in FIG. 9. Exemplary partitioned features 1030 are shown in FIG. 10.

[0124] At block 1208, a synthetic data sample is generated by combining features from two feature sets, each relating to two different entities of the set of uniquely identifiable entities. For example, each data sample may be associated with a particular uniquely identifiable entity directly (e.g., via a current unique identifier for the entity) or indirectly (e.g., via a particular location in the data matrix), such that the context portion of the data sample may be swapped with the context portion of another data sample that is not directly or indirectly associated with a particular uniquely identifiable entity.

[0125] At block 1210, method 1200 comprises assigning a label to the synthetic data sample indicating the presence of an anomaly. For example, this may comprise assigning a numerical value of 1, as shown in label 1076 in FIG. 10 . Because the synthetic data sample was generated based on a mismatch between observable features and context features, it may be understood as a positive example of an anomaly for training. At block 1212, the original training set obtained at block 1202 is augmented with the synthetic data sample. This may comprise concatenating the synthetic data sample to the bottom of a data matrix whose rows represent the data samples obtained at block 1202, and concatenating “1” labels to occurrences of “0” labels. Block 1212 may also include shuffling the data samples following augmentation (but preserving the correspondence between the data samples and the assigned labels).

[0126] Finally, at block 1214, method 1200 comprises training a supervised machine learning system using the augmented training set and the assigned labels. This may comprise applying a known training procedure using the augmented training set and the assigned labels as training data. The supervised machine learning system may be an implementation of one or more of machine learning systems 160, 210, 402, 508, 600, 700, or 940. The supervised machine learning system may comprise, for example, one or more of an ensemble system based on a set of decision trees and a recurrent neural network, as described in the previous examples. Following training, for example, following determination of a set of learned parameter values, the trained supervised machine learning system is configured to use the learned parameter values ​​to output a value indicating the presence of an anomaly when provided with a new data sample.

[0127] In some cases, observable features are derived from functions of transaction data within a predefined time window for the current transaction. For example, this may comprise a defined time range (such as within 24 hours) and / or a defined number of transactions (e.g., the last three actions). The predefined time window may relate, for example, to a first set of transaction data 1110 as shown in FIG. 11A. Contextual features are then derived from transaction data outside the predefined time window. For example, these may be derived from a second set of transaction data 1120 as shown in FIG. 11A.

[0128] One or more of the observable features may comprise aggregate metrics calculated from the transaction data for a predetermined time period defined relative to the time of the current transaction. For example, these observable features may comprise statistical metrics (such as the mean, mode, or median) or functions such as those learned by neural network mapping. For example, the predetermined time period may relate to a set of transaction data, such as the first set of transaction data 1110 as shown in FIG. 11A. In this case, block 1202 may comprise, for a given data sample, obtaining transaction data for the current transaction, the transaction data comprising an identifier for a uniquely identifiable entity, and obtaining lookup data for the uniquely identifiable entity. For example, the data sample may include a unique identifier for a user, account holder, or merchant. The obtained lookup data may comprise auxiliary data, such as 148 in FIGS. 1A-1C or 242 in FIGS. 2A and 2B. The unique identifier may be used to retrieve auxiliary data (e.g., metadata) indexed by the identifier, i.e., belonging to the identified user, account holder, or merchant. Transaction data for the current transaction is used to derive a first feature set, and the retrieved lookup data is used to derive a second feature set. Block 1202 may also comprise obtaining transaction data for the uniquely identifiable entity for a time window and calculating one or more aggregated metrics from the transaction data. For example, the unique identifier may also be used to obtain data similar to the first set of transaction data 1110 shown in FIG. 11A, and one or more aggregated metrics may be calculated from this data to derive the first feature set. In some cases, historical transaction data may also be obtained for the uniquely identifiable entity.This historical transaction data may comprise transaction data that is outside the time window, such as the second set of transaction data 1120 in Figure 11 A. One or more aggregated metrics may be calculated from the historical transaction data and used to derive the second set of features.

[0129] 9 and other examples, a supervised machine learning system trained by method 1200 may comprise a binary classifier that outputs values ​​within a predetermined range representing the likelihood of an anomaly. A label indicating the absence or presence of an anomaly may then comprise two numeric values, such as 0 and 1 or −1 and 1, allowing a numeric loss to be calculated for the training.

[0130] In some examples, at least block 1214 may be executed at regular intervals to retrain the machine learning system. In this case, the data augmentation techniques of method 1200 may be applied to increasingly available data since the last execution of block 1214. In this case, the generated labeled training data, i.e., new data produced by the repetition of blocks 1202-1212 on new data, may be concatenated with previously available data, i.e., to increase the size of the training set.

[0131] Exemplary Methods for Detecting Anomalies Figure 13 illustrates an example method 1300 for detecting anomalies in transaction data. The example method 1300 may be integrated with the example transaction process flows 500 and 550 of Figures 5A and 5B, with suitable adaptations for applying a supervised machine learning system trained using the training methods described with reference to Figures 9-12.

[0132] At block 1302, method 1300 comprises receiving transaction data for anomaly detection. This may comprise operations similar to block 522 in FIG. 5A. The transaction data may relate to a proposed transaction, for example, as described with reference to blocks 512-518 in FIGS. 5A and 5B. The transaction data may be received as a data packet accompanying an API request, for example, for an internal function or an external RESTful interface. At block 1304, a first set of features is generated based on the received transaction data. This may be performed as part of one of blocks 522 or 524 in FIGS. 5A and 5B or as part of blocks 522 or 524. This may comprise applying an observable feature generator 910 to generate an observable feature vector 916, as described with reference to FIG. 9. The first set of features may be configured as a vector of numerical values ​​calculated based at least on the data packet accompanying the API request, i.e., data for the proposed transaction.

[0133] At block 1306, method 1300 comprises determining a uniquely identifiable entity associated with the received transaction data. This may comprise, for example, parsing the API request and extracting an identifier for one or more of the user for the proposed transaction and the merchant for the proposed transaction. At block 1308, method 1300 comprises obtaining auxiliary data associated with the uniquely identifiable entity. This may comprise obtaining data such as one or more of auxiliary data 148, 242, and 922 in FIGS. 1A-1C, 2A-2B, and 9. The auxiliary data may also comprise or be computed from historical transaction data such as one or more of transaction data 146, 240, and 924 in FIGS. 1A-1C, 2A-2B, and 9. If an identifier is extracted, it may be used to locate and / or filter historical transaction data based on the uniquely identifiable entity, for example, to retrieve transaction data related to a particular user account.

[0134] At block 1310, a second set of features is generated based on the obtained auxiliary data. This may comprise applying a context feature generator 920 to generate a context feature vector 926 as described with reference to FIG. 9 . The second set of features may be represented as numerical values ​​in a vector representation. In some cases, historical transaction data may be processed to determine one or more of the values ​​for the vector representation. For example, one or more statistical metrics may be calculated from the historical transaction data, and / or the historical transaction data may be processed by one or more neural network architectures to extract features based on a set of trained parameters. These parameters may be trained using parameters of a machine learning system, as described below. In some cases, block 1310 may comprise obtaining historical transaction data for a uniquely identifiable entity, where the historical transaction data comprises transaction data that falls outside a defined time window for the received transaction data. In this case, block 1310 may comprise calculating one or more aggregated metrics from the historical transaction data and generating a second feature set from at least the one or more aggregated metrics.

[0135] At block 1312, input data is generated for a supervised machine learning system based on the generated first and second sets of features. The supervised machine learning system may comprise one or more implementations of the machine learning systems 160, 210, 402, 600, 700, and 940 described above. The supervised machine learning system is trained based on a training set comprising a historical data sample and a synthetic data sample. The synthetic data sample is generated by combining features from the first and second sets of features from the historical data sample, each relating to two different entities of the set of uniquely identifiable entities, e.g., two different users or merchants. For example, the training set may comprise the augmented training set 1070 shown in FIG. 10 , where the synthetic data sample comprises synthetic data sample 1050 and the historical data sample comprises the original training set 1010. The synthetic data samples are assigned a label indicating the presence of an anomaly for training (e.g., a “1,” as shown at label 1076 in FIG. 10 ), and unlabeled data samples in the historical data samples are assigned a label indicating the absence of an anomaly for training (e.g., a “0,” as shown at label 1076 in FIG. 10 ). Training may comprise applying available model fitting functions in a machine learning computer program code library. In cases where the supervised machine learning system comprises a neural network architecture, training may comprise applying backpropagation with gradient descent, which uses a loss function based on the difference between the predictions output by the supervised machine learning system and the assigned labels. Training may be performed in a configuration stage prior to application of method 1300. For some machine learning systems, training may be applied online as more data is generated (e.g., as more transactions are approved or rejected, as demonstrated in FIGS. 5A and 5B ).Depending on the supervised machine learning system selected, both offline and online training methods may be used. Generating the input data may comprise generating an input feature vector similar to the input feature vector 930 shown in Figure 9. In some cases, if not already performed, preprocessing may be applied to generate the input data, including converting textual and categorical data to numerical equivalents, normalizing the data, dimensionality reduction, etc.

[0136] At block 1314, a supervised machine learning system is applied to the input data. This may comprise performing a forward pass of the supervised machine learning system, sometimes referred to as an "estimation" step. The supervised machine learning system comprises a binary classifier configured to output a value indicative of the presence of an anomaly. For example, the output value may comprise a scalar value, such as output 416 or 950 in FIGS. 4 and 9. The value may be normalized (e.g., using a sigmoid nonlinearity) to fall within the range of 0 to 1. This may be performed as described with reference to block 524 in FIGS. 5A and 5B.

[0137] At block 1316, the incoming transaction data is selectively labeled based on the value output by the supervised machine learning system. This may be performed based on the output by the supervised machine learning system (e.g., as described with reference to FIG. 4) and / or by a separate computing device, such as the payment processor system 506 at blocks 528 or 552 in FIGS. 5A and 5B. The labeling may comprise sending a response to the original API request with a scalar value. It may also comprise applying one or more custom post-processing calculations, such as applying a threshold to output a binary label of “anomalous” or “not anomalous.”

[0138] In some cases, block 1316 may comprise approving or rejecting the transaction based on the output of the supervised machine learning system. This may comprise generating control data for controlling whether at least one transaction in the transaction data is accepted or rejected based on the value output by the supervised machine learning system. For example, in a simple case, a threshold may be applied to the output of the supervised machine learning system, and values ​​greater than the threshold (representing an “abnormal”) may be rejected, values ​​less than the threshold (representing a “normal” action) may be approved, with a preferred decision being made for values ​​equal to the threshold. In some cases, such as those shown in FIGS. 1A-1C and 5A-5B, the transaction data may be received from a point-of-sale device regarding a transaction to be approved. In these cases, block 1316 may comprise approving the transaction response for the value output by the supervised machine learning system being less than a predetermined threshold.

[0139] In some examples, block 1316 comprises selectively flagging a uniquely identifiable entity associated with the received transaction data based on the value output by the supervised machine learning system. For example, this may comprise flagging a user or merchant as fraudulent.

[0140] Some examples related to the second aspect of Figures 9-13 address the technical problem of training a machine learning system to indicate whether a transaction involves expected (i.e., normal) or unexpected (i.e., anomalous) behavior, where behavior simply refers to a set of actions taken with respect to one or more electronic systems over time. The examples address a problem involving transaction processing, i.e., where there is a repository of available data, but this typically represents unlabeled historical data, and unexpected behavior is inherently rare (e.g., less than 10% of cases are "unexpected"). Therefore, machine learning engineers cannot use many traditional tools, such as those designed based on the assumption of a Gaussian ("normal") distribution, whereas anomalies are typically characterized by a power-law distribution. Machine learning engineers further face a lack of labeled data for training machine learning systems. These problems are also not widely recognized in the art of machine learning, and it is common for machine learning engineers to demonstrate no solution or to trial and apply unsupervised learning techniques that do not produce high-confidence results that can be used in production systems.

[0141] In contrast, this example of the second aspect solves the problem of identifying a large class of anomalous transactions in poorly labeled situations. A machine learning system is proposed to identify transactions where observed (i.e., measured) interactions with a computing system differ from expected interactions, either based on past interactions or on auxiliary information. In this example, a training method is proposed that works by augmenting available data and re-posing the problem as a supervised learning problem. This enables the use of powerful supervised learning algorithms that can identify anomalies that more closely align with deviations from expected interactions than comparison-based machine learning systems. In practice, the proposed example allows supervised machine learning to be trained to more accurately label transactions as fraudulent. An implementation of this example has been successfully tested in a production environment where transactions need to be processed at high volume (1,000-2,000 transactions per second) with sub-second latency. The machine learning systems described herein are specifically designed to output a simple scalar value, which still allows binary approvals to be based on the output, yet allows the machine learning configurations to be trained in the manner described herein and configured for large-scale production implementation; the scalar value is small yet useful because it effectively collapses a large body of input information (e.g., a high-dimensional input vector) into a singular point of information. In testing, this scalar value can be used for transaction approval, which avoids false positives that can wear out and halt production systems, while also identifying true positives that are consistent with hand-labeled anomalies. This has the broader benefit of avoiding large-scale criminal abuse of electronic payment systems.

[0142] There are several comparison-based approaches to detecting anomalies in datasets, including unsupervised outlier detection, synthetic minority over-sampling technique (SMOTE), "Snorkel" systems, semi-supervised learning systems, and active learning systems.

[0143] In unsupervised outlier detection, features deemed useful for quantifying deviations from expected behavior are generated, and the features are then input into an anomaly detection system configured to identify features within a population of features that are outliers relative to the overall data distribution of those features. Techniques for performing unsupervised outlier detection include using tree-based separation forests, generative adversarial networks, or variational autoencoders. An and Cho, "Variational Autoencoder Based Anomaly Detection using Reconstruction Probability," a paper by An and Cho (SNU Data Mining Center, 2015-2 Special Lecture at IE), incorporated herein by reference, describes an anomaly detection method that uses reconstruction probabilities from variational autoencoders. However, these techniques are complex and difficult to reconcile with transaction processing constraints.

[0144] SMOTE, as described in the paper of the same name by Chawla et al., published in Journal of Artificial Intelligence Research 16 (2002) 321-357, which is incorporated herein by reference, describes a technique for oversampling minority (abnormal) classes from data samples and undersampling majority (normal) classes. However, this technique relies excessively on data samples labeled as “abnormal,” with resulting accuracy issues. The Snorkel system is described in a paper by Ratner et al., entitled “Snorkel: Rapid Training Data Creation with Weak Supervision,” (published on arXiv on November 28, 2017), which is incorporated herein by reference. It allows users to train machine learning models without manually labeled data. It is primarily designed for text-based medical data and explores incorporating a weak source of supervision by applying user-assigned labels to a decomposed context hierarchy. However, the Snorkel system is not well suited to the type of data used in transaction processing systems, and the probabilistic method of generative labeling introduces potential accuracy issues for production transaction processing systems. It also requires a source of "expert" labels.

[0145] Semi-supervised learning methods address situations where there is some labeled training data but possibly batches of unlabeled data. Most semi-supervised methods infer (implicitly or explicitly) likely labels for unlabeled data points, allowing them to be used in training. However, like unsupervised methods, semi-supervised methods tend to be more complex and sensitive to hyperparameter configurations. They also rely on a small set of high-confidence labels. Active learning methods label a subset of data and then use an oracle (such as a human expert) to apply labels to a wider set of unlabeled data using this labeled subset. However, oracles have limited capacity, and it is important to make careful choices about which data points to send to the oracle. Therefore, active learning focuses primarily on selecting which unlabeled data points to send to the oracle in order to learn as much as possible as quickly as possible.

[0146] Thus, while these approaches attempt to address the label sparsity problem in general settings, they tend to be inappropriate for the transaction processing context and do not help solve the problem of detecting unexpected patterns of action within that transaction data.

[0147] Some examples of training machine learning systems described herein operate based on the availability of large, unlabeled datasets covering previously processed transactions, where each piece of data, such as the transaction data described with respect to FIGS. 1A-1C, is associated (e.g., indexed) with a uniquely identifiable entity, such as a cardholder or merchant. Examples described herein partition input data into a two-feature-set tuple {C, O}, where "C" denotes a set of "contextual" machine learning features and "O" denotes a set of "observable" machine learning features. This tuple may relate to a specific action undertaken by an entity related to an electronic payment processing system, e.g., a proposed transaction. It may also, in other cases, relate to actions over an aggregated period, such as a week's activity. In these examples, the observable features are computed based on raw observations of such actions, or a stateful aggregation of a time period including actions, such as all actions initiated within a 24-hour period. The action here may relate to the submission of a request for payment to a payment processor system. Observable features may be viewed as observations of an entity's current or recent behavior, as expressed through their actions. Contextual features may be computed based on a broader set of auxiliary data that can be used to predict the observable features. Contextual features may depend on what data sources are available and / or the configuration of the machine learning system that receives the input data on which to make a prediction.

[0148] Some examples described herein may be used in several ways to facilitate payment processing and detecting unexpected patterns of activity. In some cases, contextual features may be calculated based on the likelihood of interactions with other entities, such as different merchants, entities located in different geographic regions, different recipient entities, etc. In this case, the scalar value output by the machine learning system may be used to help determine whether a malicious third party has gained access to payment data (e.g., “hacking” account details and attempting to make fraudulent payments). In other cases, the scalar output may be used to identify misuse of an electronic system, such as opening an account with incorrect information. In these cases, the machine learning system may be used to identify transaction history for an entity that contradicts or does not match pre-disclosed information. For example, in these cases, observable features comprising the frequency, value, and destination of transactions over a defined time period may be used, and contextual features that summarize metadata associated with the entity, such as age, occupation, country of residence, etc., may be used. In still other cases, the scalar output of the machine learning system may be used to determine whether a merchant is engaging in suspicious activity, such as detecting patterns of electronic behavior that do not match expectations based on historical or disclosed data. For example, the contextual features in this case may comprise characteristics of the entity, including location information. This example may be applied in each of these cases.

[0149] Some examples described herein propose a data augmentation method for training that synthesizes binary labels for unlabeled historical training data. In this method, existing data samples {C, O} in the historical training data are assigned a label indicating the absence of anomalies. Synthesized tuples (i.e., data samples) {C, O'} or {C', O} are then generated by combining contextual features and observable features that exist separately but not together in the training data. For example, C from one {C, O} associated with entity_1 is paired with O' from another {C', O'} associated with entity_2. Once trained on this augmented dataset, a machine learning system can be applied to the new data samples {C*, O*} to determine whether an anomaly exists. The output of the machine learning system can be used as is or can provide the basis for further processing pipelines (e.g., as input features to another machine learning system trained to predict other output data).

[0150] Some examples described herein address the problem of anomaly detection in transactional data as a supervised learning problem that uses a combination of data partitioning of input feature vectors and a data augmentation process to provide associated labels. Because the observable features of reliably labeled data samples may be drawn from the observed actions of various entities and are thus generated from the contextual features of various entities, the data augmentation process ensures that the “anomaly” label indicates an anomaly in the action pattern. This produces a more accurate scalar output than comparison-based approaches that utilize variance-based unsupervised anomaly detection to detect anomalies relative to expectations related to the entity's context. Through the current training process, trained supervised machine learning systems “learn” to more highly consider specific types of data anomalies correlated with deviations from the entity's expected actions. In contrast, traditional unsupervised outlier detection methods treat all data anomalies as equally interesting, regardless of whether the anomalies are correlated with deviations from the expected actions for the entity, and do not take into account, for example, temporal correlations and patterns within those actions.

[0151] Some examples related to the second aspect described herein enable the training of machine learning systems for transaction processing that do not require reliably labeled data “anomalies.” This distinguishes the approach from comparison-based upsampling, weakly supervised, and semi-supervised approaches. Furthermore, some examples described herein address not only the problem that positive (i.e., anomalous) data samples may be losing labels, but also the problem that positive data samples may be rare in the first place, which is not addressed by weakly supervised and semi-supervised approaches. When ground truth labels exist but are incredibly rare, comparison-based approaches in upsampling, weak labeling, active learning, and semi-supervised learning cannot address the limitations in the diverse action patterns encoded in labeled data. The described examples enable the generation of a large number of relevant positive (i.e., anomalous) labels, making it easier for supervised machine learning systems to learn complex decision boundaries and automate feature extraction (e.g., through embedding), both of which lead to improved performance. Moreover, some of the examples described herein do not require an "oracle" to be present to label data points on demand, as in the case of active learning approaches, nor do our approaches require input from a human expert or from a proxy signal, as in the case of weakly supervised approaches.

[0152] Some examples herein describe a transaction processing system comprising: a transaction processing module (such as first processing stage 603 of FIG. 6A ) configured to receive first information related to a first proposed transaction, retrieve second information related to at least one prior transaction related to the first proposed transaction, and calculate a time-delayed algorithm using the second information to generate third information; and a weighting module (such as second processing stage 604 of FIG. 6A ) communicatively coupled to the transaction processing module, wherein the weighting module is configured to receive the third information from the neural-based processing module, apply a weighting factor to the third information to generate fourth information, and calculate at least one processing algorithm using the first information and the fourth information to generate an output, the output being used by additional transaction processing modules to determine whether the first proposed transaction is fraudulent. In some examples, a method for detecting fraudulent transactions is also described, the method comprising: receiving, by a transaction processing module, first information related to a first proposed transaction; retrieving, by the transaction processing module, second information related to at least one prior transaction related to the first proposed transaction from a storage repository; computing, by the transaction processing module, a time-delayed algorithm using the second information to generate third information; receiving, by a weighting module, the third information from the transaction processing module; applying, by the weighting module, a weighting factor to the third information to generate fourth information; and computing, by the weighting module, at least one processing algorithm using the first information and the fourth information to generate an output, the output being used by additional transaction processing modules to determine whether the first proposed transaction is fraudulent.

[0153] Some examples described herein may be implemented via instructions stored in a computer-readable storage medium. The computer-readable medium may comprise one or more of a rotating magnetic disk, a rotating optical disk, a flash random access memory (RAM) chip, and other mechanically moving or solid-state storage media. During use, instructions are executed by one or more of the processors to cause the processors to perform the operations described above. The above embodiments, variations, and examples are to be understood as illustrative. Further embodiments, variations, and examples are contemplated. While some components of each example are described separately, it should be understood that functionality described with reference to one example may be suitably implemented in another example, and that some components may be omitted depending on the implementation. It should be understood that any feature described with respect to any example may be used alone or in combination with other described features, as well as in combination with one or more features of any other of the examples or any combination of any other of the examples. For example, features described with respect to system components may also be adapted to be performed as part of the described method. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention as defined in the appended claims. [Explanation of symbols]

[0154] 100, 102, 104 Transaction processing system 110 client devices 120 Computer Networks 130 Commercial Servers 140 Payment Processor Server 142 first data storage device 144 second data storage device 146 Transaction Data 148 Ancillary Data 150 Machine Learning Servers 160 Machine Learning Systems 162 input data 164 output data 170 Local Data Storage Device 172 Ancillary Data 200, 202 Data storage configuration 210 Machine Learning Systems 220 Data Bus 230, 232 data storage device 240 historical transaction data 242 Ancillary Data 250 data transfer channels 260 Data Storage Device 270 Logical Memory Layer 280 division 300 records 310 Current Transaction Data 320 Historical Transaction Data 402 Machine Learning Systems 410 Input Data 412 Input Data Interface 414 Machine Learning Model Platform 416 Scalar Output 418 Alarm System 420 Output Data Interface 422 Output Data 502 POS or user device 504 Commercial Systems 506 Payment Processor (PP) System 508 Machine Learning (ML) Systems 510 Issuing Bank System 600 Machine Learning Systems 601 Input Data 602 Scalar Output 603 First Processing Stage 604 Second Processing Stage 606 Transaction Time Data, Time Difference Interface, Time Difference Input Interface 608 Transaction characteristic data, incoming transaction data, input transaction data 610 First Multilayer Perceptron 618 Transaction Data Entry Interface 620 Recurrent Neural Network Architecture 622 Status Input Interface 624 Status Output Interface 626 Oblivion Gate 628 Time difference encoding φ d 630 Output Data 632 Multiplication 634 Combinatorial Logic 660 Attention Neural Network Architecture 662 Time-delayed interface 664 History Input Interface 666 Current Input Interface 668 Time difference encoding φ e 670 Connecting Block 672 Value Vector Calculation Operations 674 Key Vector Calculation Operation 676 Query Vector Calculation Operation 678 First Dot Product Operation 680 Time difference encoding φ w 682 Combinatorial Logic 684 Softmax Operation 686 Second Dot Product Operation 688 output data 690 Second Multilayer Perceptron 692 First Skip Connection 694 Second Skip Connection 710 input feature vectors 720, 722, 724, 726 Decision Tree 730, 732, 734, 736 classification values 740 Ensemble Processor 750 Final scalar output 810 training data 812 feature data 814 Label 840 Machine Learning Systems 842 parameters 850 classification 860 Training Engine 900 Machine Learning System 910 Observable Feature Generator 912, 914 Transaction Data 916 Observable Feature Vectors 920 Context Feature Generator 922, 924 auxiliary data 926 context feature vectors 930 input feature vectors 940 Binary Classifier 942 parameters 950 Scalar Output 1000 Pipelines 1010 Training Set 1012 data samples 1020 Data Division Stage 1030 Segmented Data 1032 First feature set 1034 Second feature set 1040 Synthetic Data Generation Stage 1050 synthetic data samples 1052, 1054 mixed pairs 1060 Data Labeling Stage 1070 Augmented Training Set 1072 Observable Characteristics 1074 Context Features 1076 Labels 1100 Transaction Data 1102 Proposed Transactions 1110 First set of transaction data 1120 Second set of transaction data 1140 feature vectors

Claims

1. A computer-implemented method for training a supervised machine learning system to detect anomalies in transaction data, comprising: obtaining a training set of data samples, each data sample derived at least in part from transaction data and associated with one of a set of uniquely identifiable entities, at least a portion of the training set being unlabeled; assigning a label indicating the absence of anomalies to unlabeled data samples in the training set; partitioning data of the data samples in the training set into two feature sets, a first feature set representing observable features and a second feature set representing contextual features, the observable features being derived from a function of at least transaction data for a current transaction, and the contextual features being derived from one or more of a function of historical transaction data excluding the current transaction and retrieved data related to the uniquely identifiable entity for the current transaction; generating a synthetic data sample by combining features from the two feature sets that relate to two different entities of the set of uniquely identifiable entities, respectively; assigning a label to the synthetic data sample indicating the presence of an anomaly; augmenting the training set with the synthetic data samples; training a supervised machine learning system using the augmented training set and the assigned labels; the trained supervised machine learning system is configured to output a value indicating the presence of an anomaly when provided with a new data sample; method.

2. 2. The method of claim 1, wherein the observable features are derived from functions of transaction data within a predetermined time window for the current transaction, and the contextual features are derived from transaction data outside the predetermined time window.

3. 3. The method of claim 2, wherein one or more of the observable features comprise aggregate metrics calculated from transaction data over a predetermined time period defined relative to a time of the current transaction.

4. The step of obtaining a training set of data samples includes, for a given data sample: obtaining transaction data for a current transaction, the transaction data comprising an identifier for a uniquely identifiable entity; obtaining lookup data for the uniquely identifiable entity; the obtained transaction data is used to derive the first feature set, and the obtained lookup data is used to derive the second feature set; The method of claim 3.

5. The step of obtaining a training set of data samples comprises, for the given data samples: capturing transaction data for the uniquely identifiable entity during the time window; calculating one or more aggregated metrics from the transaction data; the one or more aggregated metrics are used to derive the first feature set; The method of claim 4.

6. The step of obtaining a training set of data samples comprises, for the given data samples: obtaining the historical transaction data for the uniquely identifiable entity, the historical transaction data comprising transaction data that falls outside the time window; calculating one or more aggregated metrics from the historical transaction data; the one or more aggregated metrics are used to derive the second feature set.

6. The method of claim 4 or 5.

7. The method of claim 1 , wherein the second set of features comprises metadata associated with the corresponding uniquely identifiable entity.

8. 8. The method of claim 1, wherein the supervised machine learning system comprises a binary classifier that outputs a value within a predetermined range representing the likelihood of an anomaly, and the label indicating the absence or presence of an anomaly comprises two numerical values ​​representing a binary output.

9. 9. The method of claim 1, wherein the supervised machine learning system comprises an ensemble system based on a set of decision trees.

10. 9. The method of claim 1, wherein the supervised machine learning system comprises a recurrent neural network.

11. A computer-implemented method for detecting anomalies in transaction data, comprising: receiving transaction data for anomaly detection; generating a first set of features based on the received transaction data; determining a uniquely identifiable entity associated with the received transaction data; obtaining auxiliary data relating to the uniquely identifiable entity; generating a second set of features based on the acquired auxiliary data; generating input data for a supervised machine learning system based on the generated first and second sets of features, wherein the supervised machine learning system is trained based on a training set comprising historical data samples and synthetic data samples, the synthetic data samples being generated by combining features from the first and second sets of features from the historical data samples, each relating to two different entities of a set of uniquely identifiable entities, the synthetic data samples being assigned a label indicating the presence of an anomaly with respect to training, and unlabeled data samples in the historical data samples being assigned a label indicating the absence of an anomaly with respect to training; applying the supervised machine learning system to the input data, the supervised machine learning system comprising a binary classifier configured to output a value indicative of the presence of an anomaly; selectively labeling the received transaction data based on the values ​​output by the supervised machine learning system; A method for providing

12. 12. The method of claim 11 , wherein selectively labeling the received transaction data comprises selectively flagging the uniquely identifiable entities associated with the received transaction data based on the values ​​output by the supervised machine learning system.

13. generating control data for controlling whether at least one transaction in the transaction data is accepted or rejected based on the value output by the supervised machine learning system.

13. The method of claim 11 or 12, comprising:

14. obtaining auxiliary data relating to the uniquely identifiable entity, obtaining historical transaction data for the uniquely identifiable entity, the historical transaction data comprising transaction data that falls outside a time window defined for the received transaction data; calculating one or more aggregated metrics from the historical transaction data; the one or more aggregated metrics are used to generate a second feature set.

14. The method according to any one of claims 11 to 13.

15. 15. The method of claim 11, wherein the transaction data is received from a point-of-sale device for a transaction to be approved, and wherein selectively labeling the received transaction data comprises approving a transaction response to which the value output by the supervised machine learning system is less than a predetermined threshold.

Images