US 12,333,526 B2
Systems and methods for payment token provisioning with variable risk evaluation
Craig M. Mullaney, Newark, DE (US); David Christopher Carey, Middletown, DE (US); Sridhar Aravamudhan, Middletown, DE (US); Julia Elyasheva, Woodmere, NY (US); and Alwin M. Thomas, Newark, DE (US)
Assigned to JPMORGAN CHASE BANK, N.A., New York, NY (US)
Filed by JPMORGAN CHASE BANK, N.A., New York, NY (US)
Filed on Jan. 27, 2021, as Appl. No. 17/159,457.
Claims priority of provisional application 62/966,400, filed on Jan. 27, 2020.
Prior Publication US 2021/0233066 A1, Jul. 29, 2021
Int. Cl. G06Q 20/36 (2012.01); G06Q 20/02 (2012.01); G06Q 20/32 (2012.01); G06Q 20/38 (2012.01); G06Q 20/40 (2012.01); G06F 16/955 (2019.01); G06Q 40/02 (2023.01)
CPC G06Q 20/3674 (2013.01) [G06Q 20/02 (2013.01); G06Q 20/3224 (2013.01); G06Q 20/326 (2020.05); G06Q 20/3672 (2013.01); G06Q 20/385 (2013.01); G06Q 20/40145 (2013.01); G06Q 20/4016 (2013.01); G06Q 20/405 (2013.01); G06F 16/955 (2019.01); G06Q 40/02 (2013.01)] 17 Claims
OG exemplary drawing
 
1. A method for payment token provisioning with variable risk evaluation, comprising:
receiving, by an issuer backend for an issuer comprising at least one computer processor and from an electronic wallet application executed by a mobile electronic device and from a payment network, a device-bound payload comprising an identification of a card to be provisioned to the mobile electronic device and an identification of the mobile electronic device, wherein the card is issued to a cardholder;
determining, by the issuer backend, that the card is eligible for provisioning to the mobile electronic device;
generating, by the issuer backend, a card payload and communicating the card payload to the payment network, wherein the card payload comprises a subset of the payload received from the electronic wallet application, and the payment network creates a device-bound payment token for the card comprising payment token origin information, wherein the device-bound payment token is restricted to use with the mobile electronic device and comprises an identification of the electronic wallet application, an identification of the issuer, and an identification of mobile electronic device at a time of provisioning;
receiving, by the issuer backend, a link for a provisioning payload for the device-bound payment token from the payment network;
assessing, by the issuer backend, device ownership history for the mobile electronic device;
generating, by the issuer backend, a risk profile for the device-bound payment token, wherein the risk profile is based on the device ownership history of the mobile electronic device, a location history for the mobile electronic device received from the mobile electronic device, and an identification of an authentication processes associated with a request for the generation of the device-bound token;
restricting, by the issuer backend, use of the device-bound payment token based on the risk profile;
receiving, by the issuer backend, a one-time passcode from the payment network;
dynamically selecting, by the issuer backend, a communication channel out of a plurality of communication channels for sending the one-time passcode, wherein the selection of the communication channel is based on a velocity of attacks on each of the plurality of channels;
sending, by the issuer backend, the one-time passcode to contact information for the cardholder via the selected communication channel, wherein the electronic wallet application is configured to receive the one-time passcode and to forward the one-time passcode to the payment network for validation;
activating, by a third-party processor backend, the device-bound payment token in response to the validation;
receiving, by the payment network, the device-bound payment token as part of a transaction;
performing, by the payment network, domain-specific decisioning on the transaction; and
performing, by the issuer backend, risk-based decisioning on the transaction based on the risk profile associated with the device-bound payment token;
wherein the transaction is rejected in response to the domain-specific decisioning or the risk-based decisioning failing.