Managing Tokenization Risk

Marqeta has a set of risk rules that are used to determine the type of flow that will be used during wallet provisioning. The logic behind the provisioning flow is defined by internal rules, wallet provider-specific rules (such as Apple Pay), and your ability to create network rules for Marqeta. Marqeta’s default approach to token provisioning is the green flow, which means that tokens are approved and activated without any cardholder intervention. Provisionings can only be processed as green flow when the conditions described in this page are met. The green, yellow, and red flows are defined below:

Green flow – The token is approved and activated without further cardholder action.
Yellow flow – The cardholder must provide additional verification (“step-up”) to prove their identity for manual and card-on-file provisioning.
Red flow – Marqeta has declined the provisioning request and a token will not be created. The cardholder cannot make payments.

Cardholder verification

If step-up is required, Marqeta will return one of the following verification methods to the cardholder. Marqeta supports the following cardholder verification methods:

In-app verification – Your app verifies the cardholder’s identity using your own business logic. You make an API call to transition the digital wallet token, based on your decision regarding verification. The user must have your application installed already, or will need to install it to perform the verification. This method is not automatically supported, so you must first develop this method within your application.
One-time passcode (OTP) – The Marqeta platform sends a verification passcode to the cardholder using email or SMS, if those options were provided to Marqeta. The cardholder enters the passcode into the digital wallet for identity verification. The Marqeta platform transitions the digital wallet token to ACTIVE.
Customer service number – Your cardholders must call your customer service center. Using the Marqeta Dashboard or API, your customer service desk can transition the token to ACTIVE, which allows the token to be used.

One-time passcode

Program name

The program name can be configured on the Marqeta platform so that you can tailor the SMS messages you send to your cardholders. This name can be configured in only one place and the program name that you designate there will be used across your entire program.

Activation correspondence

Note
In the following examples of cardholder correspondence:• {code} represents the activation code
• {program} represents your configured program name
• {last four} represents the last four digits of the card
• {wallet} represents the digital wallet type

SMS OTP

One-way SMS messages to supported countries will use your company name or brand as the alphanumeric Sender ID. Alphanumeric Sender IDs may be up to 11 characters long. Accepted characters include both upper and lowercase ASCII letters, the digits 0 through 9, and the space character. See the following example of an activation message: Subject: Customizable sender ID
Body: Your activation code is {code} for adding your {program} card {last_four} to {wallet}. This code expires in 30 minutes. We will never ask you to share this code.

Email OTP

Subject: Card activation code for digital wallet
Body: Your activation code is {code} for adding your {program} card {last_four} to {wallet} Pay. To complete activation, please enter this code when prompted. This code expires in 30 minutes. No one will ever ask you for this code – do not provide it if asked via phone, email, chat, etc. If you did not initiate this request, contact us immediately.

Fraud and risk guidance

Provisioning risk rules

Red flow

Marqeta has several red flow rules in place that have been mandated by Apple and other businesses to protect cardholders from fraud by ensuring that card details and card state are correct, which will allow provisioning. If any of the following conditions are met, the token provisioning attempt will automatically be rejected through red flow, and cardholders will be unable to tokenize their card.

PAN, expiration, and CVV2 do not match any card on the Marqeta platform.
Card found, but is not in an ACTIVE state, has expired, or has been declared lost or stolen.
Acting cardholder is not in an ACTIVE state in the Marqeta platform.
Number of provisioning attempts with incorrect CVV2 exceeded five in the last 24 hours.
Apple device score equals 1, indicating a high risk device. This pertains to Apple Pay only.
Customer has disabled tokenization provisioning during card product configuration.
Network risk rule executed, resulting in a STIP decline and a notification sent to Marqeta.
The network was unable to reach Marqeta and provided a STIP decline notification.

Marqeta card and cardholder checks During the provisioning flow, Marqeta completes several checks on the card and cardholder to ensure that the card is in the correct state for successful token provisioning. If any of these checks fail, Marqeta will reject the token provisioning via red flow. See the following sample code and table for reference:

JSON

{
  "type": "token.activation-request",
  "state": "DECLINED",
  "response": {
    "code": "1915",
    "memo": "Invalid card security code (CVV2)"
  },
  "digital_wallet_token": {
    "state": "REQUEST_DECLINED",
    "fulfillment_status": "REJECTED",
    "issuer_eligibility_decision": "invalid.cvv2"
  }
}

Decision codes for token provisioning

Code	Memo	Issuer Eligibility Decision
`1001`	Card expired	`card.expired`
`1002`	Card suspicious	`card.suspicious`
`1003`	Card suspended	`card.suspended`
`1004`	Card stolen - pickup	`card.stolen`
`1005`	Card lost	`card.lost`
`1806`	Card not active	`card.not.active`
`1813`	Cardholder not active	`cardholder.not.active`
`1874`	Card suspicious - Expiration mismatch	`card.expiration.mismatch`

Apple Pay device score mandatory rule As a part of Apple’s requirements when provisioning via ApplePay, issuers are required to ensure that provisioning attempts will be rejected via red flow when the device score is equal to 1. See the following sample code for reference.

JSON

{
  "type": "token.activation-request",
  "state": "DECLINED",
  "response": {
    "code": "1890",
    "memo": "Security violation"
  },
  "digital_wallet_token": {
    "state": "REQUEST_DECLINED",
    "fulfillment_status": "REJECTED",
    "issuer_eligibility_decision": "low.device.score",
    "wallet_provider_profile": {
      "device_score": "1"
    }
  }
}

CVV2 attempts exceeded As a part of Apple’s requirements when provisioning via ApplePay, issuers are required to ensure that provisioning attempts are declined when authentication attempts using CVV2 have exceeded five within 24 hours. After this limit has been reached, provisioning will be declined for 24 hours and then rejected via red flow. This rule applies to all wallet providers and all networks. See the following sample code for reference.

Note
Visa typically blocks this type of provisioning request themselves, so the request would not go through Marqeta.

JSON

{
  "type": "token.activation-request",
  "state": "DECLINED",
  "response": {
    "code": "1890",
    "memo": "Security violation"
  },
  "digital_wallet_token": {
    "state": "REQUEST_DECLINED",
    "fulfillment_status": "REJECTED",
    "issuer_eligibility_decision" : "cvv.attempt.limit.exceeded"
  }
}

Tokenization provisioning disabled You have the option to enable or disable tokenization provisioning for each provisioning method at the card product level. You can disable the tokenization provisioning for any card type and Marqeta will decline these cards using red flow. See the following code sample for reference.

JSON

{
  "type": "token.activation-request",
  "state": "DECLINED",
  "response": {
    "code": "1890",
    "memo": "Security violation"
  },
  "digital_wallet_token": {
    "state": "REQUEST_DECLINED",
    "fulfillment_status": "REJECTED",
    "issuer_eligibility_decision": "token.activation-request.decline.config"
  }
}

Tokenization network stand-in Tokenization Stand-in Processing transactions (STIPs) can occur if you configure rules within the Visa Risk Manager (VRM) tool for your program that result in red flow. STIPs can also occur if the network is unable to reach Marqeta. STIP notifications inform you that the network has declined the token provisioning on behalf of you and Marqeta. See the following sample code for reference.

JSON

{
  "type": "token.activation-request",
  "state": "DECLINED",
  "response": {
    "code" : "1895",
    "memo" : "Token Activation Request - STIP Decline"
  },
  "digital_wallet_token": {
    "state": "REQUEST_DECLINED",
    "state_reason" : "decline decision due to TSP risk manager",
    "fulfillment_status": "REJECTED",
    "issuer_eligibility_decision": "token.activation-request.decline.stip"
  }
}

Yellow flow

Marqeta has several yellow flow rules in place. Some yellow flow rules are mandated by Apple. Other rules allow for additional flexibility if the issuer wants to force cardholder verification as a way to lower the provisioning risk. This section describes the rules that trigger a yellow flow for token provisioning requests:

Manual or Card-On-File provisioning method – The Apple recommendation is DECISION_YELLOW and the reason codes provided do not contain the memo 03 - Apple ID/Card pair is newer than date threshold. These constitute approximately 50% of manual requests.
In-App provisioning method – The Apple recommendation is DECISION_YELLOW, and the reason codes provided contain 0G - Orange recommendation. These constitute approximately 2.5% of Apple Pay in-app requests.
Visa recommendation is DECISION_YELLOW – A rule has been written in the VRM tool that recommends yellow flow. This allows for custom rules by the issuer.
Manual or In-App provisioning methods – Marqeta’s address verification service (AVS) has determined that the address provided in the request does not match the one on the Marqeta platform.

Note
AVS is mandated in the US, UK, and Canada.

Apple Pay yellow flow recommendation Marqeta will enforce step-up verification for provisioning attempts that meet the following criteria:

The request is either of type Manual (KEY_ENTERED)or Card-On-File (ON_FILE). The wallet provider risk reason code is not 03 - Apple ID/Card pair is newer than date threshold.
Apple has recommended DECISION_YELLOW.

This is typically seen across approximately 50% of Apple Pay provisioning requests. See the following code sample for reference.

JSON

{
  "type": "token.activation-request",
  "digital_wallet_token": {
    "state": "REQUESTED",
    "fulfillment_status": "DECISION_YELLOW",
    "issuer_eligibility_decision" : "token.activation.verification.required",
    "token_service_provider": {
      "token_requestor_name": "APPLE_PAY"
    },
    "wallet_provider_profile": {
      "risk_assessment": {
        "score": "DECISION_YELLOW"
      },
      "pan_source": "KEY_ENTERED",
      "reason_code": "09"
    }
  }
}

Orange flow

The risk reason code 0G - Orange indicates that the wallet provider recommends orange flow for an in-app provisioning attempt. Marqeta will enforce Step-Up verification in this case. This is typically seen across approximately 2.5% of Apple Pay In-App provisioning requests. See the following sample code for reference.

JSON

{
  "type": "token.activation-request",
  "digital_wallet_token": {
    "state": "REQUESTED",
    "fulfillment_status": "DECISION_YELLOW",
    "issuer_eligibility_decision" : "token.activation.verification.required",
    "token_service_provider": {
      "token_requestor_name": "APPLE_PAY"
    },
    "wallet_provider_profile": {
      "risk_assessment": {
        "score": "DECISION_YELLOW"
      },
      "pan_source": "MOBILE_BANKING_APP",
      "reason_code": "0G"
    }
  }
}

Marqeta address verification service (AVS) step-up

You can choose to enable the optional address verification service (AVS) on token provisioning requests. This will force Marqeta to validate the address provided by the wallet provider. If the address and postal code do not match, then Marqeta will enforce yellow flow. Marqeta recommends enabling AVS for Manual and Card-On-File options. However, using AVS during in-app provisioning flows can introduce friction during tokenization. If you are using in-app provisioning, you should have high confidence in the cardholder’s identity, as provisioning requests will be instigated from within your app. See the following sample code for reference.

JSON

{
  "type": "token.activation-request",
  "digital_wallet_token": {
    "state": "REQUESTED",
    "state_reason": "Additional identity verification required",
    "fulfillment_status": "DECISION_YELLOW",
    "issuer_eligibility_decision": "token.activation.verification.required"
  },
  "address_verification": {
    "response": {
      "code": "0101",
      "memo": "Address and zip code does not match"
    }
  }
}

Fraud readiness

In preparation for launch, Apple requires you to complete a Fraud Readiness document, outlining how you will be supporting various aspects of the provisioning cycle. This section describes how Marqeta supports mandatory Apple Pay rules. Apple Pay Rule #1: If the device score equals 1, then the provisioning request must be declined. When the device score within a provisioning request is equal to 1, Marqeta’s platform will reject the provisioning request via red flow and the token request will be declined. Your program is configured for this behavior by default, in accordance to ApplePay guidelines. Apple Pay Rule #2: If the following reason codes are present together (OG, OB, 03, and 01,) or (04 and 09), or simply (0A), then the issuer must decline the request. You must create a rule in your network’s risk management tool that will issue a red flow that declines the provisioning request when the specific reason codes are provided together. Mastercard risk management requires that tokens remain in the REQUESTED state in the Marqeta platform at the end of the flow. Apple Pay Rule #3: If Apple recommends orange flow (if the OG reason code is present) and the user successfully completes authentication through a strong method, the issuer must monitor early-life transactions. Orange recommendations should not be authenticated through less-secure methods such as an inbound call center. Marqeta sends the reason_code field for all tokens. You can store this data within your system and use it to mark tokens for monitoring for all early-life transactions. Multiple codes can be used here, so you should look for comma-separated lists in the reason_code field.

Apple Pay reason codes

Apple Pay provides risk assessment as a part of the token provisioning process, so as to provide insight into the account, device, and cardholder when determining whether to include the provisioning attempt. Marqeta utilizes these codes in the risk rules, but they can also be used to report and monitor tokens with higher associated risk.

Code	Description
`01`	Apple ID too new relative to launch.
`02`	Apple ID too new relative to provisioning request.
`03`	Apple ID/Card pair is newer than the date threshold.
`04`	Change made to account data within date threshold.
`05`	Suspicious transactions linked to this account.
`06`	The account has not had activity in the last year.
`07`	Suspended cards in the secure element.
`08`	The device was put in lost mode in the last 7 days for longer than the duration threshold.
`09`	The number of provisioning attempts on this device in 72 hours exceeds the threshold.
`0A`	Higher number of different cards attempted to be provisioned to the device in 24 hours.
`0B`	The provisioning request contains a distinct name in excess of the permitted threshold.
`0C`	Device score is less than 3.
`0D`	Account score is less than 4.
`0E`	Device provisioning location outside of iTunes home country.
`0F`	Model rules not available at this time.
`0G`	Orange recommendation.
`0H`	Phone number score is less than 3.

Reporting fraud

Apple Pay and Google Pay require fraud reporting to strengthen the overall ecosystem. When terminating fraudulently created tokens, use reason code 08.

Guides

​Cardholder verification

​One-time passcode

​Program name

​Activation correspondence

​SMS OTP

​Email OTP

​Fraud and risk guidance

​Provisioning risk rules

​Red flow

​Yellow flow

​Orange flow

​Marqeta address verification service (AVS) step-up

​Fraud readiness

​Apple Pay reason codes

​Reporting fraud

Cardholder verification

One-time passcode

Program name

Activation correspondence

SMS OTP

Email OTP

Fraud and risk guidance

Provisioning risk rules

Red flow

Yellow flow

Orange flow

Marqeta address verification service (AVS) step-up

Fraud readiness

Apple Pay reason codes

Reporting fraud