Digital Wallet Provisioning Fraud
Adding stolen card credentials to a mobile wallet or token on an attacker-controlled device, usually by defeating issuer step-up verification, then spending the token in-store, in-app or online.
What it is
Tokenization was supposed to make card data theft less valuable. A wallet token is bound to a device and backed by device-level authentication. But the token is only as trustworthy as the provisioning decision that created it. If an attacker can get a victim's card approved onto their device, they get all of the token's advantages: it looks like a low-risk wallet transaction, it works at contactless terminals, and per-transaction cryptograms make it look strongly authenticated.
The decision sits with the issuer, informed by the wallet provider and the network token service. Visa's token service, for example, sends ID&V attributes to the issuer at eligibility check and at approval so the issuer can approve, decline or step up; step-up methods commonly include a one-time passcode delivered to contact data on file (Visa Developer).
Industry shorthand describes three paths:
| Path | Outcome | Where fraud gets in |
|---|---|---|
| Green | Approved with no extra cardholder action | Wallet/network risk assessment misses an ATO or stolen-card pattern |
| Yellow | Step-up ID&V required: SMS/email one-time code, call to issuer, or issuer app authentication | The victim is socially engineered into giving up the code, or the call center is talked through verification |
| Red | Declined; no token created | None, since no token exists |
Most of the fraud flows through the yellow path. Issuer-processor documentation notes wallet risk recommendations send a large share of manually entered card requests to step-up (roughly half, in one processor's reporting), so step-up method choice is the decisive control (Marqeta).
How it works
Conceptually: capture card data from the victim (typically through a phishing lure) → request provisioning on a fraudster-controlled device → trigger issuer step-up → obtain the verification from the victim under a pretext, or pass a weak call-center check → the token goes live → spend or sell the device.
From the defender's side, the victim's own phone received a legitimate issuer message and the victim acted on it. Every control that relies on "the cardholder has the phone" passes.
Transaction footprint
| Stage | What you see in the data | Decision point |
|---|---|---|
| Lead-up | Recent contact detail change, password reset, or a failed login; card details entered on a phishing site leave no trace at the issuer | Account Change Events feed into provisioning risk |
| Provisioning request | Manual card entry (not push-provisioned from the issuer app); new device or wallet account; device provisioning many cards; wallet country differs from the cardholder's; wallet risk reason codes | Provisioning decision: approve, step-up method, decline |
| Step-up | OTP requested and entered within seconds; call-center verification by someone with partial knowledge; several cards stepped up from one device | Choice of step-up channel; call-center scripts |
| Activation to first use | First token transaction within minutes or hours; high-value or high-resale merchants; geography far from cardholder history | Early-life token monitoring; per-token limits |
| Spend | Rapid sequence of contactless or in-app purchases; gift cards and electronics; small transactions at suspicious merchants | Real-time scoring of token transactions |
| Dispute | Cardholder denies purchases; the PAN may still be "good" for other channels | Suspend token, reissue card, link analysis on the device |
The fraud happens at the provisioning event, but the loss shows up in the transactions. If your fraud model only scores transactions, by the time a token transacts it already looks trusted.
Common variants
| Variant | What's different | Where it shows up |
|---|---|---|
| Phish-and-provision | Card data and OTP captured in one live session | Issuers relying on SMS OTP for step-up |
| Call-center step-up abuse | Fraudster calls the issuer and passes knowledge-based verification | Issuers that allow inbound-call activation |
| ATO-provisioning | Fraudster inside the issuer's app push-provisions to a new device; see Account Takeover (ATO) | Banks and neobanks with in-app "add to wallet" |
| Device resale | Phones preloaded with multiple victims' tokens sold for use elsewhere | Organized rings (KrebsOnSecurity, 2025) |
| Contactless relay | Tokenized payment relayed from one device to a terminal elsewhere | Emerging; complicates geography-based checks |
| Merchant token / card-on-file | Stolen card tokenized at a merchant or wallet browser profile | Ecommerce and subscription merchants |
Where it shows up
- Issuers (banks, credit unions, neobanks): own the provisioning decision and usually the loss. Fintechs on issuer-processor platforms inherit default provisioning rules unless they configure their own.
- Brokerage and Investing: brokerages that offer debit cards on cash-management accounts are issuers too, often through a partner bank. A brokerage fraud team that ignores the card program misses a path from a compromised account to spendable value.
- Retail and Ecommerce: merchants see token transactions that score as low risk; resale-heavy categories (electronics, gift cards, luxury) absorb the purchases. Merchant liability is generally lower for authenticated wallet transactions.
- Payments and P2P: wallet-linked P2P and tap-to-pay services can extend a provisioned token into other rails.
Impact
- Issuer losses on disputed token transactions, plus reissue and servicing costs.
- Compressed timelines: reporting in 2025 described the gap between card phishing and fraud shrinking from roughly 60–90 days to about 7–10 days (KrebsOnSecurity, 2025).
- Customer harm and trust: victims often believe they "verified" with their bank; the conversation about liability is difficult. Reg E and card-network zero-liability policies generally protect consumers for unauthorized card use, but how the dispute is handled shapes retention. See Regulation E and Unauthorized Transfers.
- Scale: token volumes are large. Visa reported issuing its 5 billionth token in early 2023 (W3C talk, 2023), so even a small provisioning fraud rate is material.
Red flags
- Manual provisioning onto a new device shortly after a contact change or login anomaly → Account Change Events, Login Anomalies
- Many cards from different cardholders provisioned to one device, or many provisioning attempts in a short window → Device Reputation and Linkage, Velocity Signals
- Wallet country, device locale or IP far from the cardholder's history → Geolocation and Impossible Travel
- Phone number on file recently ported or changed → Phone Risk Signals
- Inbound calls requesting wallet activation, especially with partial knowledge → Customer Contact Signals
- First token use at high-risk merchants within hours → Transaction Pattern Anomalies
- Card attributes at provisioning: card recently reissued, address-verification mismatch, card with prior compromise flags → Payment Instrument Signals
- Network or wallet-provider reason codes indicating new wallet account, many cards on device, or recent account changes → External Intelligence Feeds
Prevention and detection at a glance
| Layer | Control or signal | What it does here |
|---|---|---|
| Prevent | Risk-Based Authentication and Step-Up | Route manual or risky provisioning to the strongest available step-up, not the cheapest |
| Prevent | Device Binding and Trusted Devices, Passkeys and Phishing-Resistant Authentication | Issuer-app authentication on a known device is much harder to relay than an SMS code |
| Prevent | Customer Support Verification Protocols | Remove or harden inbound call-center activation |
| Prevent | Customer Education and Scam Warnings | OTP messages that say exactly what the code does ("adds your card to a new phone") |
| Detect | Transaction Monitoring | Early-life monitoring of new tokens; tighter limits for the first days |
| Detect | Graph Analytics | Links devices and wallet accounts across victims |
| Respond | Token suspension and card reissue | Kill the token; don't rely on PAN block alone |
Emerging variants and adversary adaptation
- Live phishing replaces breach data. Mobile-only phishing pages keep the victim on the phone that receives the code, and live operators complete provisioning within the code's validity window (KrebsOnSecurity, 2025).
- Continued reliance on SMS OTP. Many issuers still rely on SMS codes for provisioning step-up; alternatives such as issuer-app authentication exist but are less widely used (W3C talk, 2023). Issuer-processor guidance explicitly recommends strong authentication for step-up and avoiding inbound call-center verification (Marqeta).
- Expect pressure to move to the next-weakest step-up. When SMS is replaced with issuer-app approval, attackers shift to ATO of the issuer app itself, call-center social engineering, or persuading victims to approve in-app prompts. Compensating controls: device binding, contextual prompts, and post-provisioning limits.
- Relay and resale break geography assumptions. Devices preloaded with tokens and contactless relays mean the token's spending location need not match the provisioning location.
- Wallet providers are adding signals (device scores, account age, cards-per-device) that issuers can consume. Teams on issuer-processor platforms should audit default rules rather than inherit them.
Related mechanisms
- Phishing and Credential Harvesting and MFA Bypass and OTP Interception: the usual way into the yellow path
- Card-Not-Present Fraud: the same stolen data, different channel
- Card Testing: sometimes used to confirm cards before provisioning
- SIM Swap and Port-Out Fraud: an alternate route to the OTP
- Gift Card Fraud: a frequent cash-out for token spend
Real-world examples
- KrebsOnSecurity (Feb 2025) described organized phishing operations converting phished cards into mobile wallet tokens, selling phones preloaded with wallets, and using contactless relays (KrebsOnSecurity, 2025).
Sources and further reading
- Visa Developer: Token Service provisioning: issuer ID&V attributes, approve/decline/step-up, OTP verification methods
- Marqeta: Managing tokenization risk: green/yellow/red paths, wallet reason codes, step-up recommendations
- KrebsOnSecurity: How phished data turns into Apple and Google wallets (2025): phish-and-provision, device resale, relay, time-to-fraud
- W3C / Entersekt: Card provisioning talk (2023): reliance on SMS OTP; token issuance volumes
- See also Regulation E and Unauthorized Transfers and Card Network Dispute Rules