Abstract: Embodiments of the invention are directed to an automated account restoration system. In some embodiments, the system determines a state of an account based on a likelihood that the account has been compromised. If the account is determined to be in a low-risk state, then upon an successful login to that account, a verification cookie may be generated which is unique to a user device used to access the account. If the account is determined to be in a high-risk state, then system may prevent access to the account except by user devices that include a valid verification cookie.

Abstract: Embodiments are directed to methods, apparatuses, computer readable media and systems for authenticating a user on a user device across multiple mobile applications. The identity of the user is validated by encoding and subsequently validating cryptographically encrypted data in a shared data store accessible by the mobile applications tied to the same entity. Specifically, the application leverages the authentication process of a trusted mobile application (e.g. a banking mobile application) to authenticate the same user on a untrusted mobile application (e.g. a merchant mobile application).

Abstract: Embodiments are directed to the generation of a token associated with a status. The status of the token may affect how the token is treated and the types of restrictions placed on the token. The status of the token may indicate that the token is generated based on verification of secure user data. Alternatively, the status of the token may indicate that the token is generated based on insufficient user data and, as such, restrictions may be imposed on the token. The token requestor may be a mobile application, such as a merchant mobile application provisioned on a user device. In response to a token request from the merchant, the token provider issues tokens with varying status based on a confidence level. The status of the token may be indicated in terms of token assurance level.

Abstract: Embodiments are directed to the generation of a token associated with a status. The status of the token may affect how the token is treated and the types of restrictions placed on the token. The status of the token may indicate that the token is generated based on verification of secure user data. Alternatively, the status of the token may indicate that the token is generated based on insufficient user data and, as such, restrictions may be imposed on the token. The token requestor may be a mobile application, such as a merchant mobile application provisioned on a user device. In response to a token request from the merchant, the token provider issues tokens with varying status based on a confidence level. The status of the token may be indicated in terms of token assurance level.

Abstract: Embodiments are directed to methods, apparatuses, computer readable media and systems for authenticating a user on a user device across multiple mobile applications. The identity of the user is validated by encoding and subsequently validating cryptographically encrypted data in a shared data store accessible by the mobile applications tied to the same entity. Specifically, the application leverages the authentication process of a trusted mobile application (e.g. a banking mobile application) to authenticate the same user on a untrusted mobile application (e.g. a merchant mobile application).

Abstract: Techniques for securely generating and using a “fingerprint” for authentication. A server computer receives a first data set from a user device (including a first fuzzy hash of first user data on the user device). The server computer generates a first fingerprint value based on the first data set. The server computer detects an event corresponding to a user in association with the user device. The server computer identifies a baseline fingerprint value (generated based on a baseline fuzzy hash of user data on the user device). The server computer compares the first fingerprint value to the baseline fingerprint value to generate a similarity score. The server computer may determine that the similarity score exceeds a threshold value but does not represent an exact match, and, based on the similarity score, authenticate the user and update the baseline fingerprint value based on the first fingerprint value.

Abstract: Embodiments are directed to methods, apparatuses, computer readable media and systems for authenticating a user on a user device across multiple mobile applications. The identity of the user is validated by encoding and subsequently validating cryptographically encrypted data in a shared data store accessible by the mobile applications tied to the same entity. Specifically, the application leverages the authentication process of a trusted mobile application (e.g. a banking mobile application) to authenticate the same user on a untrusted mobile application (e.g. a merchant mobile application).

Abstract: Embodiments are directed to the generation of a token associated with a status. The status of the token may affect how the token is treated and the types of restrictions placed on the token. The status of the token may indicate that the token is generated based on verification of secure user data. Alternatively, the status of the token may indicate that the token is generated based on insufficient user data and, as such, restrictions may be imposed on the token. The token requestor may be a mobile application, such as a merchant mobile application provisioned on a user device. In response to a token request from the merchant, the token provider issues tokens with varying status based on a confidence level. The status of the token may be indicated in terms of token assurance level.

Abstract: Embodiments are directed to the generation of a token associated with a status. The status of the token may affect how the token is treated and the types of restrictions placed on the token. The status of the token may indicate that the token is generated based on verification of secure user data. Alternatively, the status of the token may indicate that the token is generated based on insufficient user data and, as such, restrictions may be imposed on the token. The token requestor may be a mobile application, such as a merchant mobile application provisioned on a user device. In response to a token request from the merchant, the token provider issues tokens with varying status based on a confidence level. The status of the token may be indicated in terms of token assurance level.

Abstract: Embodiments of the invention are directed to an automated account restoration system. In some embodiments, the system determines a state of an account based on a likelihood that the account has been compromised. If the account is determined to be in a low-risk state, then upon an successful login to that account, a verification cookie may be generated which is unique to a user device used to access the account. If the account is determined to be in a high-risk state, then system may prevent access to the account except by user devices that include a valid verification cookie.

Abstract: Techniques for securely generating and using a “fingerprint” for authentication. A server computer receives a first data set from a user device (including a first fuzzy hash of first user data on the user device). The server computer generates a first fingerprint value based on the first data set. The server computer detects an event corresponding to a user in association with the user device. The server computer identifies a baseline fingerprint value (generated based on a baseline fuzzy hash of user data on the user device). The server computer compares the first fingerprint value to the baseline fingerprint value to generate a similarity score. The server computer may determine that the similarity score exceeds a threshold value but does not represent an exact match, and, based on the similarity score, authenticate the user and update the baseline fingerprint value based on the first fingerprint value.

Abstract: Embodiments of the invention are directed to ceasing the renewal of a virtual access device that is dormant. Some embodiments may receive a dormancy request from an authorization server, where the dormancy request includes information identifying a virtual access device. Embodiments may determine that the virtual access device is dormant based at least on previous transactions involving the virtual access device and at least one dormancy rule. Certain embodiments may send a dormancy response to the authorization server indicating that the virtual access device is dormant. An authorization server may determine not to renew a virtual access device based at least upon the dormancy response. As such, the authorization server need not provision a mobile device with an updated virtual access device.

Abstract: Embodiments are directed to methods, apparatuses, computer readable media and systems for authenticating a user on a user device across multiple mobile applications. The identity of the user is validated by encoding and subsequently validating cryptographically encrypted data in a shared data store accessible by the mobile applications tied to the same entity. Specifically, the application leverages the authentication process of a trusted mobile application (e.g. a banking mobile application) to authenticate the same user on a untrusted mobile application (e.g. a merchant mobile application).

Abstract: Embodiments are directed to methods, apparatuses, computer readable media and systems for authenticating a user on a user device across multiple mobile applications. The identity of the user is validated by encoding and subsequently validating cryptographically encrypted data in a shared data store accessible by the mobile applications tied to the same entity. Specifically, the application leverages the authentication process of a trusted mobile application (e.g. a banking mobile application) to authenticate the same user on a untrusted mobile application (e.g. a merchant mobile application).

Abstract: Systems, apparatuses, and methods for conducting payment transactions are disclosed. In exemplary embodiments, a consumer may wish to add a tip or gratuity when paying for a good or service, such as a meal at a restaurant. Exemplary systems may generate an alert or other form of message based on the transaction, where the alert or message may include a suggested amount for a tip and/or provide the consumer with information that may be used to determine an amount for the tip. In some embodiments, the systems, apparatuses, and methods may automatically generate an estimated amount for the tip based on previously established user preferences, with the estimated amount being added to the underlying cost of the good or service when authorization is sought for the transaction.

Abstract: Embodiments of the invention are directed to ceasing the renewal of a virtual access device that is dormant. Some embodiments may receive a dormancy request from an authorization server, where the dormancy request includes information identifying a virtual access device. Embodiments may determine that the virtual access device is dormant based at least on previous transactions involving the virtual access device and at least one dormancy rule. Certain embodiments may send a dormancy response to the authorization server indicating that the virtual access device is dormant. An authorization server may determine not to renew a virtual access device based at least upon the dormancy response. As such, the authorization server need not provision a mobile device with an updated virtual access device.

Abstract: Embodiments of the invention are directed to ceasing the renewal of a virtual access device that is dormant. Some embodiments may receive a dormancy request from an authorization server, where the dormancy request includes information identifying a virtual access device. Embodiments may determine that the virtual access device is dormant based at least on previous transactions involving the virtual access device and at least one dormancy rule. Certain embodiments may send a dormancy response to the authorization server indicating that the virtual access device is dormant. An authorization server may determine not to renew a virtual access device based at least upon the dormancy response. As such, the authorization server need not provision a mobile device with an updated virtual access device.

Abstract: Embodiments of the invention are directed to human challenge response test delivery systems and methods. Specifically, embodiments of the present invention are directed to secure human challenge response test delivery services of configurable difficulty for user devices. One embodiment of the present invention is directed to methods and systems for implementing a familiar and dynamic human challenge response test challenge repository created from transaction data. The dynamic human challenge response test challenge repository may be created by a server computer receiving a plurality of transaction data. Challenge items may be extracted from the transaction data using an extraction algorithm. Furthermore, in some embodiments a challenge message may be sent to a requestor, a verification request may be received, and the verification request may be compared to the challenge message.

Abstract: Embodiments of the invention are directed to ceasing the renewal of a virtual access device that is dormant. Some embodiments may receive a dormancy request from an authorization server, where the dormancy request includes information identifying a virtual access device. Embodiments may determine that the virtual access device is dormant based at least on previous transactions involving the virtual access device and at least one dormancy rule. Certain embodiments may send a dormancy response to the authorization server indicating that the virtual access device is dormant. An authorization server may determine not to renew a virtual access device based at least upon the dormancy response. As such, the authorization server need not provision a mobile device with an updated virtual access device.

Abstract: Systems and methods for service activation using algorithmically defined keys are disclosed. A consumer who has a relationship with a first party may wish to enroll in a service provided by a third party. The first party can maintain control of such enrollments through the use of algorithmically defined keys. The algorithmically defined keys also allow the third party service provider to verify data provided by the consumer as matching data stored by the first party. The verification provides for data synchronization without requiring the third party to have access to the first parties data systems.