Edge Device Machine Learning

Techniques are disclosed in which a computing device repeatedly trains, using a stream of user data received at the computing device, a baseline model to generate a device-trained model, wherein the baseline model is trained at the computing device without providing user data included in the stream to a server computer system. In some embodiments, the computing device inputs, to the device-trained model, a set of characteristics associated with a user request received from a user of the computing device, wherein the device-trained model outputs a score for the user request. In some embodiments, the computing device transmits, to the server computer system, the score for the user request, wherein the transmitting includes requesting a decision for the user request. In some embodiments, the computing device performs an action associated with the user request in response to receiving a decision for the user request from the server computer system.

BACKGROUND

Technical Field

This disclosure relates generally to data security, and, more specifically, to techniques for automatically detecting anomalous user behavior e.g., for user account security.

Description of the Related Art

As more and more transactions are conducted electronically via online transaction processing systems, for example, these processing systems become more robust in detecting suspicious and/or unusual behavior associated with user accounts used to conduct such transactions as well as the transactions themselves. As the volume of online transactions increases, the scale for loss (e.g., financial) increases. In addition, entities participating in such transactions may lose trust in the systems processing the transactions if fraudulent transactions are allowed to proceed, causing these systems to incur further loss. Many transaction systems attempt to detect anomalies in transactions in order to prevent such loss.

DETAILED DESCRIPTION

Transaction processing systems often perform risk analysis for various different scenarios based on user interaction with the processing systems including transactions initiated by users, login attempts of users, access requests of users (e.g., for secure data), etc. As one specific example, transaction processing systems are generally configured to identify unusual characteristics associated with the millions of transactions they process daily. These risk analyses often include implementation of various anomaly detection methods. Generally, such anomaly detection methods are performed using a machine learning model trained at a server of the transaction processing system. In such situations, however, user device data must be transmitted from user devices to the server in order to be used in training the machine learning model at the server. Due to an increase in privacy measures implemented by different operating systems (e.g., iOS and ANDROID) or different browsers (e.g., SAFARI, CHROME, FIREFOX, etc.), or both on user devices, particularly with respect to private user data, transmission of user device data may be prohibited.

The disclosed techniques implement a hybrid approach to training a machine learning models for anomaly detection. For example, the disclosed techniques perform all or a portion of model training on edge devices rather than performing training at a central system. Performance of such training at edge devices instead of on a central server may be referred to herein as “federated learning.” In particular, the portion of machine learning model training that involves private user data is performed at user devices such that the private data does not leave the edge device at which the training is being performed. As such, the disclosed techniques may advantageously improve transaction security while maintaining the integrity of private user information stored at edge devices. As one specific example implementation, performance of machine learning at edge devices (e.g., user's mobile devices) may be implemented due to the 5G technology included in these edge devices. Performance of various tasks, that were previously performed at a server, at individual user computing devices may be referred to in some contexts as mobile edge computing (MEC). Implementation of the disclosed techniques at edge devices is now possible at varying low, mid, and high frequency bands extending through 5G and beyond. As another example implementation, the disclosed machine learning at edge devices may be performed using any of various network communication methods implemented over the air, including communications conducted at varying frequencies (e.g., cellular-based, Wi-Fi-based, satellite-based, etc.). Implementation of the disclosed machine learning techniques using various network communication methods may advantageously provide for lower latency and higher throughput at the user computing devices performing the machine learning while maintaining or increasing the amount of fraud prevention provided. As one specific example, the use of 5G technology may advantageously allow user computing devices to upload device-trained models to the server computer system more quickly and reliably than when using other network communication methods.

Further in disclosed techniques, machine learning models trained at edge devices may be transmitted to a central server of a transaction processing system for fine-tuning. In addition to transmitting device-trained models, edge devices may transmit private user data that has been obfuscated to the central server for use in fine-tuning the device-trained models. Once these models are tweaked at the server using the obfuscated user data, they are transmitted back to individual user devices for further use and training using private user data. In addition to performing aggregation and distribution of user-device trained models, the server provides decisioning to various edge devices by evaluating scores generated by device-trained models at the edge devices. The server performed such evaluation according to various predetermined rules and heuristics and provides user devices with results of the evaluation.

In one example anomaly detection scenario, a transaction processing system may require a user to enter their username and password each time they attempt to log in to their account prior to initiating transactions. This process, however, becomes tedious for many users and can result in high amounts of friction within the user experience, which in turn often results in low user-engagement and end-to-end conversion. For example, if a user attempts to access their account with a transaction processing system three different times to initiate three different transactions within a given day, this user may become frustrated if they have to enter their username and password each time they submit a transaction request, which may cause them to abandon their plans to initiate the second and third transaction, for example. This often results in loss for the transaction processing system or its clients, or both. The disclosed techniques perform risk analysis prior to requesting that a user input their username and password in order to provide a “silent authentication” for this user and, ultimately, effortless access to their account. This may advantageously improve user experience, which in turn increases user engagement and end-to-end conversion for transactions. Note that in various other embodiments, the disclosed techniques may be used to evaluate any of various types of user requests other than account access request, such as electronic transactions.

Hybrid Anomaly Detection

FIG.1is a block diagram illustrating hybrid anomaly detection system100. In the illustrated embodiment, system100includes user computing devices110A-110N and server computer system150. Note that the interactions discussed with reference toFIG.1between user computing device110A and server computer system150might also occur between user computing devices110B-110N and server computer system150.

User computing device110A, in the illustrated embodiment, includes baseline model120and device-trained model130A. In the illustrated embodiment, user computing device110A receives a user request102from a user120. In some embodiments, user request102is a transaction authorization request. In other embodiments, user request102is a request to access a user account. For example, a user may open a transaction processing application on their device. In this example, the user opening the application on their device may be the user request. In contrast, in this example, the user inputting their account credentials may be the user request.

User computing device110A, in the illustrated embodiment, receives a stream104of user data. The stream104of user data is a continuous flow of information into the user computing device110A. This stream of data may be continuous and includes device characteristics, characteristics associated with user120, characteristics associated with user request102, etc. For example, stream104includes one or more of the following characteristics associated with user computing device110A: location, internet protocol (IP) address, gyroscope data, hardware specifications (device ID, type of device, etc.), software specifications (browser ID, browser type, etc.), mouse/finger movements on a user interface, etc. For example, if a user swipes on their device screen or moves (a change in their geographic location) during initiation of the transaction, this information will be included in the stream104of user data. The stream104of user data may also include one or more of the following user characteristics: phone number, account name, password, payment information, physical address, mailing address, typing speed, email address, login history, transaction history, etc. In some embodiments, user characteristics are received by user computing device110A from server computer system150. For example, the phone number, transaction history, login history, etc. may be received by device110A from system150. The stream104of user data also includes characteristics associated with user request102, such as transaction information (dollar amount, time of transaction, location, etc.), account credentials, authentication factors, voice commands, etc.

In some embodiments, user computing device110A obfuscates user data using one or more privacy techniques. For example, the obfuscation performed by device110A alters the user data in such a way that other computer systems receiving the obfuscated user data are unable to identify private information included in the user data (e.g., a user's credit card information, home address, passwords, etc.). Privacy techniques are discussed in further detail below with reference toFIG.2. User computing device110A, in the illustrated embodiment, transmits obfuscated user data116to server computer system150. In some embodiments, user computing device110A obfuscates a portion of the user data included in stream104and transmits it to system150. For example, user computing device110A may send only a portion of the data included in the stream104to system150, but obfuscates this data prior to transmission. As one specific example, if user computing device110A is an ANDROID device, the stream104of user data will include a greater amount of data than if device110A is an iOS device due to the application security measures set in place for these two different types of devices. In some embodiments, user computing device110A sends raw user data, that has not been obfuscated, to server computer system150. For example, if the stream104of user data includes information that is public knowledge (e.g., the name of the user), this information might be sent directly to server computer system150without obfuscation. In some embodiments, user computing device110A sends user data that has been transformed (e.g., has been pre-processed in some way), is in vector form, etc.

User computing device110A trains a baseline model120using one or more sets114of user data from the stream104of user data to generate device-trained model130A. User computing device110A trains baseline model120using one or more machine learning techniques. Various models discussed herein such as the baseline model120, the device-trained models130, and the updated models192are machine learning models, including but not limited to one or more of the following types of machine learning models: linear regression, logistic regression, decision trees, Naïve Bayes, k-means, k-nearest neighbor, random forest, gradient boosting algorithms, deep learning, etc.

After generating device-trained model130A, user computing device110A inputs set106of characteristics associated with user request102into model130. The set106of characteristics may include any of various user data included in stream104. For example, the set106may include information associated a transaction request submitted by user120(e.g., transaction amount, type of transaction, device location, IP address, user account, etc.) or may include information associated with an account login request received from user120(e.g., username and password, device location, IP address, etc.). Device-trained model130A outputs risk score132for the user request102based on set106of characteristics and user computing device110A transmits the risk score132to decisioning module160. Risk score132indicates an amount of risk associated with user request102based on the set106of characteristics. For example, risk score may be a classification score on a scale of 0 (e.g., not suspicious) to 1 (e.g., suspicious). As one specific example, a risk score of 0.8 output by device-trained model130A may indicate that a transaction indicated in user request102is suspicious.

In response to sending risk score132to system150, user computing device110A receives a decision162. This decision162indicates whether or not user request102is approved. Based on decision162, user computing device110A performs an action118for the request102. For example, if user request102is a transaction request, decision162may indicate to authorize the transaction. In this example, action118includes processing the transaction request. In addition, user computing device110A may send a notification to user120e.g., by displaying a message to the user via a user interface of device110A. As another example, if user request102is a request to login to a user account, decision162indicates to grant user120access to their account. In this example, user computing device110A may grant the user access to their account by displaying an account page to the user via a user interface.

In other situations, a user may open an application or a web browser on their device and navigate to an account login page (e.g., a PAYPAL login page). In such situations, the disclosed techniques may determine whether to provide this user access to their account without requiring this user to enter their account credentials. For example, prior to a user entering their username and password, the disclosed techniques may implement a trained machine learning model (e.g., device-trained model130A) to determine the risk associated with granting the user access to their account without them entering their login credentials. If, according to the output of the trained machine learning model, the risk associated with granting access falls below a security threshold, the disclosed system will automatically grant the user access to their account. This process is referred to as ONE TOUCH in the PAYPAL context.

Server computer system150, in the illustrated embodiment, receives risk score132for user request102from device-trained model130A of user computing device110A. System150executes decisioning module160to generate a decision162for request102based on risk score132. For example, decisioning module160may include a plurality of rules and heuristics for different entities associated with requests, devices associated with requests, types of requests, locations, etc. Decisioning module160may receive information specifying the type of request102from user computing device110A in addition to the obfuscated user data116(which includes information about the user and the user's device). Decisioning module160selects a set of rules and heuristics for request102based on one or more characteristics indicated in obfuscated user data116.

As one specific example, a first user submitting a transaction request for a wrench from a hardware store using a debit card might be less risky than a second user submitting a transaction request for a diamond ring from a pawn shop using a credit card. In this specific example, decisioning module160might select rules and heuristics with a higher tolerance threshold for the first user's transaction than for the second user's transaction. Further in this specific example, the requests from the first user and the second user might have similar risk scores132; however, decisioning module160approves the first request and rejects the second request based on the risk tolerance threshold for the first request being greater than the risk tolerance threshold for the second request. Said another way, small transactions at a trusted merchant (e.g., a hardware store) may less risky than larger transactions at an unknown merchant (e.g., a pawn shop). As another specific example, two transaction requests submitted within the same local network (e.g., at a particular hardware store) might be evaluated using different risk thresholds. For example, a first transaction request for power tools might be evaluated using a lower risk threshold than a transaction request for a set of nails. As yet another example, transactions submitted at different vendors located at the same shopping mall may be evaluated using different risk threshold.

In some embodiments, decisioning module160performs risk analysis differently for different entities submitting a request. For example, in the context of an electronic transaction between a customer and a merchant, the merchant may be able to assume a greater amount of risk than the customer. Further in this context, a mature merchant (e.g., one that has been completing transactions for years and at a large volume) may have more room for risk than a newer merchant, so decisioning module160evaluates transaction requests from these two merchants differently (e.g., using different sets of rules). As another example, person-to-person electronic transactions might be evaluated differently than person-to-merchant transactions. As yet another example, if a funding instrument (e.g., a credit card) is known to be suspicious, this might affect the evaluation performed by decisioning module160. Still further, a gourmet coffee merchant might have a high profit margin and, therefore, is willing to evaluate transactions using a higher risk threshold (e.g., is willing to be more lenient with risk and may allow transactions associated with a moderate level of risk) while a merchant selling silver coins might have a low profit margin and, as such, evaluates transactions using a lower risk threshold (e.g., is not lenient with risk and denies slightly risky transactions).

In addition to generating decision162, server computer system150receives device-trained models130A-130N from user computing devices110A-110N and performs additional training on these models. Before performing additional training, server computer system150evaluates the performance of various device-trained models130using similarity module170and performance module180. Similarity module170, in the illustrated embodiment, receives device-trained models130from user computing devices110and determines similarity scores for models that have similar obfuscated user data116. Similarity module170is discussed in further detail below with reference toFIG.4.

Performance module180, in the illustrated embodiment, determines, based on the similarity scores172generated by similarity module170, one or more low-performance models182. For example, performance module180determines that two models are similar based on their similarity score172and then compares the performance of these two models. In some embodiments, performance module180identifies low-performance models182based on these models performing more than a threshold amount differently than their identified similar counterparts. As one specific example, if a first model of two similar models is 90% accurate in its classifications and a second model is 70% accurate in its classifications, then performance module180identifies the second model as a low-performance model182based on this model performing more than 10% below the first model. Performance module180sends the identified low-performance model to training module190for additional training. Performance module180is discussed in further detail below with reference toFIG.4.

Training module190, in the illustrated embodiment, performs additional training on one or more low performance models182received from performance module180. In some embodiments, training module190retrains device-trained model130A using obfuscated user data116from a plurality of different user computing devices110B-110N. For example, instead of device-trained model130A being trained only on user data from user computing device110A, server computer system150retrains model130A using data from a plurality of different user computing devices110. In other embodiments, training module190generates an aggregate model from a plurality of device-trained models130. Training module190may repeat this retraining process for device-trained models130received from user computing devices110. Training performed by module190is discussed in further detail below with reference toFIG.4. Server computer system150, in the illustrated embodiment, transmits one or more updated models192to one or more of user computing devices110.

As used herein, the term “baseline model” refers to a machine learning model that a given user computing device begins using without the model having been trained at the given user computing device previously. For example, a baseline model may have been trained previously at another user device or at the server computer system150and then downloaded by the given user computing device. The baseline model may be a machine learning model that is trained by system150to identify account takeovers (ATOS) completed by fraudulent users, for example. This type of baseline model may be referred to as an ATO model. As used herein, the term “device-trained model” refers to a machine learning model that has been trained to some extent at a user computing device using a stream of user data received at the user computing device. Device-trained model130A is one example of this type of model. Device-trained models generally are maintained and executed on user computing devices (e.g., on edge devices) As used herein, the term “updated model” refers to a machine learning model that is generated at a server computer system from one or more device-trained models. For example, an updated model might be an aggregate of a plurality of device-trained models trained at different user computing devices. Alternatively, an updated model might be a single device-trained model that has been retrained in some way by server computer system150.

In this disclosure, various “modules” operable to perform designated functions are shown in the figures and described in detail (e.g., decisioning module160, similarity module170, performance module180, training module190, etc.). As used herein, a “module” refers to software or hardware that is operable to perform a specified set of operations. A module may refer to a set of software instructions that are executable by a computer system to perform the set of operations. A module may also refer to hardware that is configured to perform the set of operations. A hardware module may constitute general-purpose hardware as well as a non-transitory computer-readable medium that stores program instructions, or specialized hardware such as a customized ASIC.

Various disclosed examples are discussed herein with respect to identification of fraudulent behavior. Note, however, that the disclosed device-side machine learning techniques might be applied any of various situations. For example, the disclosed device-side machine learning may be implemented to personalize a user interface or user experience, or both, provide personalized recommendations, etc.

Example User Computing Device

Turning now toFIG.2, a block diagram is shown illustrating an example user computing device110A. In the illustrated embodiment, user computing device110A includes secure storage212and application240, which in turn includes sanity check module220, privacy preservation module210, training module250, and updated model130.

Application240, in the illustrated embodiment, receives user request102from user120and stream104of user data. In some embodiments, application240stores user data included in stream104in secure storage212such that other devices cannot access the user data. Secure storage212may be any of various types of storage such as those discussed below in further detail with reference toFIG.7(e.g., storage712). For example, the stream104may include private user data that application240is not able to share with other computer systems due to user privacy measures implemented by the operating system of user computing device110A prohibiting transmission of private user data off device. In some situations, stream104of user data include only a portion of the user data available to user computing device110A. For example, application240may not have access to all of the user data available to user computing device110A due security measures set in place on certain user computing devices. Application240may be downloaded onto user computing device110A from an application store, for example, by user120. In some embodiments, application240is associated with a transaction processing service. For example, application240may be a PAYPAL application facilitating online electronic transactions. In situations in which user computing device110A is a mobile device, application240is a mobile application. When user computing device110A is a desktop computer, for example, application240may be accessed via a web browser of the desktop computer.

Sanity check module220receives stream104of user data and determines whether this data follows an expected statistical summary. In some embodiments, sanity check module220remediates the impact of anomalies in the user data (e.g., originating from system issues such as timeouts, from the user request itself, etc.). For example, sanity check module220may compare a vector of incoming user data to statistical vectors generated using a statistics aggregator included in sanity check module220. As one specific example, sanity check module220may compare an incoming vector of user data in a multivariate manner to statistical distance measures (e.g., Mahalanobis distance, Bhattacharya distance, Kullback-Leibler divergence metrics, etc.). The statistics aggregator may also perform a temporal assessment using multi-variate moving averages and splines. Such techniques may cap incoming user data by one or more deviations from the median vectors to which they are compared due to numerical values beyond a given capped coefficient lacking value when using the user data to train machine learning models. In some situations, sanity check module220leaves a portion of the incoming user data uncapped.

As one specific example, if the mean, median, etc. of the incoming user data align with the mean, median, etc. values of the statistical vectors, then the stream of user data is sent directly to training module250and privacy preservation module210. For example, the statistics aggregator may select a snapshot of user data from 15 minutes prior to a current timestamp and compare this to user data included in the stream104and associated with the current timestamp. If the data form the current timestamp differs a threshold amount from user data in the snapshot from 15 minutes ago, then the sanity check module220adjusts the user data from the current timestamp. If, however, the values of incoming user data do not align with the statistical feature vectors, then sanity check module220alters the incoming data to generate adjusted user data222. Adjusted user data222is then sent to privacy preservation module210for obfuscation and device-trained model130for predicting a score132for user request102.

Training module250, in the illustrated embodiment, includes feature module260and baseline model120. Feature module260performs one or more feature engineering processes on the adjusted user data222prior to using this data to train baseline model120. Feature engineering processes performed by feature module260are discussed in further detail below with reference toFIGS.3A and3B. Once feature module260generates pre-processed user data, training module250trains baseline model120using one or more machine learning techniques and the pre-processed data to generate device-trained model130. In some embodiments, training module250repeatedly trains baseline model120as new user data is received. For example, training module250may train a baseline model120at a time t1using a set of user data including data received prior to time t1and then perform additional training on the baseline model120at time t2using a set of user data including at least data received between time t1and time t2. In this way, baseline model may be updated as new user data is received at application240.

Privacy preservation module210, in the illustrated embodiment, receives adjusted user data222from sanity check module220and performs one or more privacy techniques on the data to generate obfuscated user data116. The privacy techniques performed by privacy preservation module210include: differential privacy, homomorphic encryption, secure multi-party computation, etc. Differential privacy, for example, includes providing information about a set of data by describing patterns of groups within the set of data while withholding information about individuals in the set of data. Homomorphic encryption permits computations on encrypted data without first requiring that the data be decrypted. For example, results of performing computations on homomorphically encrypted data is identical to the output produced when such computations are performed on an unencrypted version of the data. Secure-multi-party computation allows multiple different entities to perform computations for their grouped data while maintaining the privacy of each individual entities data. For example, this cryptographic method protects the privacy of the different entities data from other entities whose data is included in the grouped data.

Example Feature Engineering

As discussed above with reference toFIG.2, user computing device110A trains a model using machine learning techniques; however, prior to performing such training, the user computing device110A may perform feature engineering on user data to be used for training.FIG.3Ais a block diagram illustrating an example training module250. InFIG.3A, user computing device110includes training module250, which in turn includes feature module260and a baseline model120. Feature module260inFIG.3Aincludes real-time module310, caching module320, lookup module330, and temporal module340.

Feature module260, in the illustrated embodiment, receives adjusted user data222and generates pre-processed features362. Feature module260generates pre-processed features362using one or more pre-processing techniques. For example, feature module260may execute one or more of real-time module310, caching module320, lookup module330, and temporal module340to generate pre-processed features362. Example pre-processing techniques that may be implemented by one or more of modules310-340include descaling, weight-of-evidence, mid-max scalar, edge detection, etc. In some embodiments, when executing one or more of modules310-340, feature module260implements at least two different pre-processing techniques. For example, when the adjusted user data222includes both continuous and categorical features, feature module260may implement both descaling and weight-of-evidence techniques. In some embodiments, training module250uses pre-processed features362, generated by feature module260, to generate a directed acyclic graph (DAG). In some embodiments, training module250uses the DAG to train baseline model120.

In some embodiments, pre-processed features362are included in a vector of features for a given user request. In some embodiments, these vectors of features are included in a feature matrix generated for a plurality of user requests received at a given user computing device. For example, a matrix of feature vectors might include feature vectors for user requests received at user computing device110A within the past 24 hours.

Real-time module310performs on-the-fly data processing. Said another way, real-time module310pre-processes adjusted user data222as it is received. For example, as new user requests102are received at user computing device110A and as new data comes in from the stream104of user data, real-time module310performs pre-processing techniques.

Caching module320receives adjusted user data222and stores this data in a cache until a threshold number of characteristics are received in user data222and stored in the cache. For example, the threshold may specify a number of unique characteristics (e.g., one account number, one email address, one location, one device ID, etc.), a total number of characteristics including repeats, a total number of values for a given variable, a total amount of time, etc. Once the threshold number of characteristics is satisfied, caching module320performs one or more feature pre-processing techniques on the data stored in the cache. As one specific example, caching module320may store 100 different characteristics included in user data222in a cache before performing feature transformations on these characteristics. In this specific example, the threshold number of characteristics is 99. As another specific example, caching module320may perform pre-processing on data values stored in a cache after a predetermined time interval. For example, caching module320may perform pre-processing techniques on data stored in a cache every five minutes. In some embodiments, caching module320stores features generated by performing preprocessing on the characteristics included in user data222in the cache.

The cache utilized by caching module320may be an AEROSPIKE cache, for example. The cache utilized by caching module320may be a key-value store. After performing one or more feature pre-processing techniques on the values of the given feature, caching module320may store this pre-processed feature in the key-value store cache. For example, caching module320may store the data value for a given variable as the key and store the preprocessed feature for the given variable as the value in the key-value store.

Lookup module320performs a lookup for training module250as adjusted user data222is received. For example, based on receiving a particular piece of user data, lookup module320checks, in a key-value store (such as the store implemented by caching module320), whether this piece of data matches a key in the key-value store. If the piece of data does match a key, lookup module320retrieves the value corresponding to this key and returns it to feature module260as a pre-processed feature362. For example, the keys of the key-value store include raw user data, while the values of the key-value store include user data that has already been pre-processed in some way.

Temporal module340generates a matrix of feature vectors that includes feature vectors generated using adjusted user data222from different intervals of time. For example, the matrix of feature vectors may include data from the past 24 hours, past 15 minutes, past 15 seconds, etc. As one specific example, if the matrix of feature vectors includes data from the past 24 hours, then the matrix may include 96 different feature vectors with user data from different 15-minute time intervals. As new adjusted user data222is received at feature module260, temporal module340updates the matrix of feature vectors e.g., by implementing a first-in/first-out method. In this way, temporal module340maintains a matrix by continuously refreshing the matrix as new user data is received.

Turning now toFIG.3B, a diagram is shown illustrating the example flow from adjusted user data to the generation of a device-trained model130. For example, the adjusted user data222received by training module250as shown inFIG.3Bmay include a plurality of different characteristics included in user data collected by user computing device110A (e.g., from the stream104of user data shown inFIG.1). InFIG.3B, the plurality of different characteristics are pre-processed (by training module250) to generate vectors of pre-processed features362. Then, inFIG.3B, the vectors of pre-processed features362are used (by training model250) to train baseline model120using machine learning techniques to generate device-trained model130.

Example Server Computer System

Turning now toFIG.4, a block diagram is shown illustrating an example server computer system150. In the illustrated embodiment, system400includes a model repository450and server computer system150, which in turn includes decisioning module160, similarity module170, performance module180, and training module190. The training discussed with reference toFIG.4is performed by server computer system150to ensure that models trained at user computing devices110are satisfying a performance threshold since these models are primarily trained at the user devices on user data available at the given device. In this way, server computer system150is able to provide checks and balances to ensure that models trained at user computing devices have not become skewed in some way.

Decisioning module160, in the illustrated embodiment, includes rule selection module470and comparison module480. Rule selection module470receives obfuscated user data116from user computing device110A and selects a set464of rules from a plurality of security rules462(e.g., for evaluating user request102) based on the obfuscated user data116. In some embodiments, rule selection module470receives a portion of user data that is not obfuscated. As such, rule selection module470may select a set464of rules for evaluating user request102based on the user data that has not been obfuscated or user data that has been obfuscated, or both. These rules may include any of various types of rules including service-level agreements, risk thresholds, etc.

Rule selection module470then passes the selected set464of rules to comparison module480. In some situations, decisioning module160makes a decision for user request102by both comparing the risk score to a risk threshold and also comparing a non-obfuscated characteristic to a characteristic threshold. If one or both of the risk score and non-obfuscated characteristic satisfy their respective thresholds, then decisioning module160may send instructions to the user computing device specifying to require further user authentication. For example, if a transaction amount (an example characteristic) is greater than a certain amount (a transaction amount threshold), then decisioning module160may request further authentication prior to authorizing the transaction.

In other embodiments, decisioning module160implements a risk threshold for a plurality of different user computing devices. For example, decisioning module160may compare a risk score from a user computing device with the risk threshold without receiving user data (obfuscated or not) and without selecting a set of rules for this user computing device. In this example, if the risk score satisfies the risk threshold, then decisioning module160sends instructions to the user computing device to require a user of the device to complete further authentication checks. In still other embodiments, user computing devices may include a decisioning module that makes on-device risk decisions based on risk scores output by device-trained models.

Comparison module480compares risk score132(received from user computing device110A) with the selected set464of rules. For example, comparison module480may compare the risk score132to a risk threshold included in the selected set464of rules. Based on this comparison, module480outputs a decision162for the user request102(shown inFIG.1). As one specific example, if the risk score for a given user request is 0.8 and the risk threshold is 0.6, then comparison module480may output a decision162indicating that the given user request is rejected (i.e., based on the risk score of 0.8 surpassing the risk threshold of 0.6 for this request).

In addition to providing decisions for different user requests based on risk scores132produced at user computing devices110, server computer system150provides checks and balances for device-trained models130. In this way, server computer system150advantageously identifies and corrects any unbalanced training of device-trained models130by comparing these models trained at similar user devices with one another. In particular, similarity module170, in the illustrated embodiment, receives device-trained models130from user computing devices110. Similarity module170determines similarity scores for two or more models130that are nearest neighbors. For example, similarity module170determines if two or more models are trained using similar sets114of user data based on observing obfuscated user data116received from user computing devices110that trained these similar models. As one specific example, if two devices are capturing similar user activity and training their respective models based on this similar activity, their models should be performing with similar accuracy. If, however, one of these models is performing less accurately than the other, server computer system150flags this model for retraining.

Similarity module170applies a clustering algorithm (e.g., a k-nearest neighbor algorithm, semi-supervised machine learning algorithm, etc.) on obfuscated user data116received from different user computing devices110. Based on the output of the clustering algorithm, similarity module170identifies a statistical neighborhood of devices running a set of models that are similar (e.g., one or multiple of which may be used as a head-starter model for a new user computing device). Then, performance module180takes two or more similar models identified by similarity module170and determines their performance. For example, performance module180may determine that a first model is 90% accurate (e.g., 90% of the classifications output by the first model are correct), while a second model is 80% accurate (e.g., 80% of the classifications output by the second model are correct). Performance module180then compares the performance of these models (e.g., by comparing individual classifications output by these models or by comparing the overall performance of these models, or both). If at least one of the models is performing poorly compared to its nearest neighbor models, for example, then performance module180flags this model as a low-performance model182and sends this model to training module190for additional training.

In some embodiments, instead of retraining the low-performance model182, training module190replaces the low-performance model182with one of the similar models determined by similarity module170. For example, the first model discussed above that is 90% accurate may be used by training module190to replace the second model that is 80% accurate. That is, training module190may transmit the second model to the user computing device110who trained the second, 80% accurate model. In this example, the replacement model that is 90% accurate is one of the “updated model192” shown inFIG.4that is sent from training module190to user computing devices110. In other embodiments, training module190executes distribution check module420and aggregation module180to generate updates models192to replace low-performance models182identified by performance module180.

Aggregation module180performs one or more ensemble techniques to combine two or more device-trained models130to generate aggregated models412. For example, aggregation module410takes the coefficients of two or more device-trained models130and combines them using one or more ensemble techniques, such as logistic regression, federated averaging, gradient descent, etc. Aggregation module410, in the illustrated embodiment, sends one or more aggregated models412to distribution check module420.

In some embodiments, aggregation module180aggregates two or more head-starter models. For example, aggregation module410may aggregate a model that is trained at server computer system150based on account takeover data, known fraudulent behavior (e.g., fraudulent transactions), etc. As one specific example, aggregation module410may aggregate a model trained on account takeover data and a model trained on fraudulent transaction data to generate an aggregated head-starter model. In some embodiments, training module190sends an aggregated head-starter model to one or more of user computing devices110. As one specific example, training module190may train a head-starter model based on data from the past week, month, year etc. Training module190then sends this model to a user computing device110that has had an application associated with server computer system150downloaded for a week, month, year, etc. The application associated with server computer system150may be an application downloaded on a user computing device such that it is operable to communicate with server computer system150to process user requests, such as transactions. In some situations, user computing devices110that are highly active (e.g., process a threshold number of user requests) send their device-trained models130to server computer system150for fine-tuning more often than user computing devices110that are not highly active (e.g., process a number of user requests below the threshold number of requests). For example, highly active devices110may send their models in for fine-tuning once a week, while other devices110only send their models in once a month for fine-tuning.

In some embodiments, distribution check module420checks whether aggregated models412are meeting a performance threshold. If, for example, an aggregated model is not meeting a performance threshold, distribution check module420may perform additional training of this model using obfuscated user data116from a plurality of different user computing devices110. For example, distribution check module420uses obfuscated user data116to fine-tune the training of aggregated models412prior to sending these updated models192to user computing devices (or storing them in model repository450, or both).

Separation module430, in the illustrated embodiment, sorts and stores various models generated by training module190in model repository450. For example, separation module430sorts updated models192or baseline models452, or both based on various characteristics. Such characteristics may include the obfuscated user data116used to train this model (e.g., domain information, geographic location, etc.), one or more device-trained models130used to generate an updated model192, etc. Training module190, in the illustrated embodiment, stores baseline models452and updated models192according to the sorting performed by separation module430. Such sorting and storage may advantageously allow server computer system150to quickly retrieve an appropriate model for a given user computing device110to replace a current, low-performance model182used by the given device110. In the illustrated embodiment, training module190retrieves one or more updated models192from model repository450and sends these models192to one or more user computing devices110.

Example Methods

FIG.5is a flow diagram illustrating a method500for training a machine learning model using embedded transaction data, according to some embodiments. The method shown inFIG.5may be used in conjunction with any of the computer circuitry, systems, devices, elements, or components disclosed herein, among other devices. In various embodiments, some of the method elements shown may be performed concurrently, in a different order than shown, or may be omitted. Additional method elements may also be performed as desired. In some embodiments, one or more of user computing device110perform the elements of method500.

At510, in the illustrated embodiment, a computing device repeatedly trains, using a stream of user data received at the computing device, a baseline model to generate a device-trained model, where the baseline model is trained at the computing device without providing user data included in the stream to a server computer system. In some embodiments, the stream of user data includes a plurality of characteristics associated with the computing device and the set of characteristics associated with the user request. For example, the stream of user data may include information about a user that needs to be kept private (e.g., banking information, social security number, physical address, etc.). In some embodiments, the baseline model and the device-trained model are machine learning models. In some embodiments, prior to repeatedly training the baseline model, the computing device receives, from the server computer system, the baseline model, where the baseline model is trained by the server computer system without the stream of user data securely stored at the computing device. For example, the baseline model may be a simple model trained at the server computer system and then sent to the computing device for device-specific training using private user data.

In some embodiments, the repeatedly training includes generating an aggregated depiction of data included in the stream of user data. In some embodiments, the repeatedly training includes generating an aggregated depiction of data included in the stream of user data. In some embodiments, the repeatedly training includes adjusting the stream of user data based on one or more portions having data that differ a threshold amount. For example, the computing device may compare new feature vectors (generated from the stream of user data) of different transactions based on their timestamps to determine whether these feature vectors are following the known aggregated depiction of feature vectors. As one specific example, the computing device determines whether a current transaction has similar features to a transaction requested fifteen minutes ago.

In some embodiments, the repeatedly training includes performing one or more feature engineering techniques on a plurality of characteristics included in the stream of user data, where the one or more feature engineering techniques are performed according to one or more conditions of the following conditions: on-the-fly processing, lookup-based processing, and cache-based processing. For example, the featuring engineering techniques may include pre-processing the plurality of characteristics included in the stream of user data using one or more pre-processing techniques discussed above with reference toFIG.3A.

At520, the computing device inputs, to the device-trained model, a set of characteristics associated with a user request received from a user of the computing device, where the device-trained model outputs a score for the user request. In some embodiments, the user request received from the user of the computing device is a request to initiate a transaction, where the decision for the user request is an authorization decision for the transaction. In some embodiments, the user request received from the user of the user computing device is an authentication request to authenticate the user of the user computing device to a user account, where the decision for the user request is an authentication decision.

At530, the computing device transmits, to the server computer system, the score for the user request, where the transmitting includes requesting a decision for the user request. In some embodiments, the computing device obfuscates, using one or more privacy techniques, a portion of the user data. In some embodiments, the computing device transmits, to the server computer system, the obfuscated portion of the user data. In some embodiments, the one or more privacy techniques include one or more of the following techniques: differential privacy, homomorphic encryption, and secure multi-party computation.

At540, the computing device performs an action associated with the user request in response to receiving a decision for the user request from the server computer system. In some embodiments, performing the action includes automatically granting the user of the user computing device access to an account associated with the server computer system, wherein the automatically granting is performed without requiring credentials from the user.

FIG.6is a flow diagram illustrating a method600for training a machine learning model using embedded transaction data, according to some embodiments. The method shown inFIG.6may be used in conjunction with any of the computer circuitry, systems, devices, elements, or components disclosed herein, among other devices. In various embodiments, some of the method elements shown may be performed concurrently, in a different order than shown, or may be omitted. Additional method elements may also be performed as desired. In some embodiments, server computer system150performs the elements of method600.

At610, in the illustrated embodiment, a server computer system receives from a plurality of user computing devices, a plurality of device-trained models and obfuscated sets of user data stored at the plurality of user computing devices, where the device-trained models are trained at respective ones of the plurality of user computing devices using respective sets of user data prior to obfuscation. In some embodiments, the user computing devices are mobile devices.

At620, the server computer system determines similarity scores for the plurality of device-trained models, where the similarity scores are determined based on a performance of the device-trained models. In some embodiments, determining similarity scores for the plurality of device-trained models is performed based on determining, using a machine learning algorithm, two or more of the plurality of user computing devices that are similar, where the determining is performed based on characteristics specified in the obfuscated sets of user data. As one specific example, similar user computing devices are ones with at least 80% of the same user data. In some embodiments, determining similarity scores for the plurality of device-trained models is performed based on selecting, based on the two or more user computing devices that are similar, device-trained models corresponding to the two or more user computing devices that are similar. For example, the server computer system may use a k-nearest neighbor algorithm to identify nearest neighbor user computing devices in order to use models trained by the devices to provide models for new user computing devices or replace models executed by existing user computing devices, or both.

At630, the server computer system identifies, based on the similarity scores, at least one of the plurality of device-trained models as a low-performance model. For example, the server computer system may determine that one device-trained model is performing above a performance threshold, while another device-trained model is performing below the performance threshold.

At640, the server computer system transmits, to the user computing device corresponding to the low-performance model, an updated model. In some embodiments, the server computer system generates, prior to the transmitting, the updated model. In some embodiments, generating the updated model includes generating an aggregated model by combining two or more of the plurality of updated models received from the plurality of user computing devices. In some embodiments, generating the updated model further includes inputting the obfuscated set of user data received from the low-performance model into the aggregated model. In some embodiments, the server computer system stores the updated model in a database based on domain information and geographic region information.

In some embodiments, the server computer system receives, from one of the plurality of user computing devices, a risk score for a user request received at the user computing device, where the risk score is generated by the user computing device using a device-trained model. In some embodiments, the server computer system determines, based on a plurality of rules associated with the user request, a decision for the user request. In some embodiments, the server computer system transmits, to the user computing device, the decision for the user request. For example, the server computer system includes various rules and heuristics for different devices, user request, etc. and uses these rules and heuristics to provide decisions to user computing devices for the different user requests. In some embodiments, the plurality of rules associated with the user request are selected based on one or more characteristics of the following types of characteristics: a location of the user computing device, a type of user request received at the user computing device, and one or more entities indicated in the user request.

In some embodiments, the server computer system receives, from a new user computing device that has newly downloaded an application of the server computer system, a request for a baseline model. In some embodiments, the baseline model is an untrained model. In some embodiments, the user computing device generates the device-trained model from scratch. For example, the user device may train a model from scratch instead of requesting a baseline model from the server computer system. In some embodiments, the server computer system selects, from the database, an updated model, where the selecting is performed based on one or more obfuscated sets of user data received from the new user computing device. In some embodiments, the server computer system transmits, to the new user computing device, the selected updated model.

In some embodiments, one of the plurality of device-trained models is trained at a given user computing device by comparing different portions of an aggregated depiction of a stream of non-obfuscated user data gathered at the given user computing device. In some embodiments, the one device-trained model is further trained by adjusting the stream of non-obfuscated user data based on or more portions having data differing a threshold amount. In some embodiments, the one device-trained model is further trained by inputting the adjusted steam of non-obfuscated user data into a baseline model to generate the one device-trained model.

Example Computing Device

Turning now toFIG.7, a block diagram of one embodiment of computing device (which may also be referred to as a computing system)710is depicted. Computing device710may be used to implement various portions of this disclosure. Computing device710may be any suitable type of device, including, but not limited to, a personal computer system, desktop computer, laptop or notebook computer, mainframe computer system, web server, workstation, or network computer. The user computing device110shown inFIG.1and discussed above is one example of computing device710. As shown, computing device710includes processing unit750, storage712, and input/output (I/O) interface730coupled via an interconnect760(e.g., a system bus). I/O interface730may be coupled to one or more I/O devices740. Computing device710further includes network interface732, which may be coupled to network720for communications with, for example, other computing devices.

In various embodiments, processing unit750includes one or more processors. In some embodiments, processing unit750includes one or more coprocessor units. In some embodiments, multiple instances of processing unit750may be coupled to interconnect760. Processing unit750(or each processor within750) may contain a cache or other form of on-board memory. In some embodiments, processing unit750may be implemented as a general-purpose processing unit, and in other embodiments it may be implemented as a special purpose processing unit (e.g., an ASIC). In general, computing device710is not limited to any particular type of processing unit or processor subsystem.

Storage subsystem712is usable by processing unit750(e.g., to store instructions executable by and data used by processing unit750). Storage subsystem712may be implemented by any suitable type of physical memory media, including hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RDRAM, etc.), ROM (PROM, EEPROM, etc.), and so on. Storage subsystem712may consist solely of volatile memory, in one embodiment. Secure storage212discussed above with reference toFIG.2is one example of storage subsystem712. Storage subsystem712may store program instructions executable by computing device710using processing unit750, including program instructions executable to cause computing device710to implement the various techniques disclosed herein.

I/O interface730may represent one or more interfaces and may be any of various types of interfaces configured to couple to and communicate with other devices, according to various embodiments. In one embodiment, I/O interface730is a bridge chip from a front-side to one or more back-side buses. I/O interface730may be coupled to one or more I/O devices740via one or more corresponding buses or other interfaces. Examples of I/O devices include storage devices (hard disk, optical drive, removable flash drive, storage array, SAN, or an associated controller), network interface devices, user interface devices or other devices (e.g., graphics, sound, etc.).

Various articles of manufacture that store instructions (and, optionally, data) executable by a computing system to implement techniques disclosed herein are also contemplated. The computing system may execute the instructions using one or more processing elements. The articles of manufacture include non-transitory computer-readable memory media. The contemplated non-transitory computer-readable memory media include portions of a memory subsystem of a computing device as well as storage media or memory media such as magnetic media (e.g., disk) or optical media (e.g., CD, DVD, and related technologies, etc.). The non-transitory computer-readable media may be either volatile or nonvolatile memory.