Wallet Provisioning Fraud: When Stolen Cards Get Added to Someone Else’s Phone

Mobile wallet payments are, transaction for transaction, among the most secure in existence: device-bound tokens, per-payment cryptograms, biometric confirmation. So criminals stopped attacking the transaction and started attacking the doorway. If a stolen card number can be enrolled into a wallet on a criminal’s phone, every one of those security properties starts working for the thief: the token launders the stolen PAN into clean tap-to-pay credentials that sail through terminals worldwide. Wallet provisioning fraud is now one of the dominant card fraud patterns precisely because wallet payments are so trusted, and the entire battle happens in the few seconds of enrollment.

Quick answer: Wallet provisioning fraud is the enrollment of stolen card details into a mobile wallet on a device the cardholder does not control. Criminals defeat the issuer’s identity and verification (ID&V) step, most often by phishing the one-time passcode from the victim in real time or by social-engineering bank call centers. Defenses center on issuer-side provisioning risk scoring, stronger verification paths than SMS codes, cardholder alerts on every enrollment, and velocity controls on new-token spending.

Why does provisioning defeat the wallet’s security model?

The wallet architecture we describe in how tokenization protects wallet payments binds a network token to a specific device and approves each payment with a one-time cryptogram. Those guarantees authenticate the device and the token, not the person who enrolled the card. The system’s honest assumption is that enrollment was legitimate; everything downstream inherits it. Enroll a stolen card successfully and the fraud gains properties ordinary stolen numbers never have: it works at physical terminals, it carries wallet-level trust in risk models, it needs no plastic to be manufactured, and the real cardholder notices nothing until charges appear. The stolen number has been upgraded.

How do criminals get through ID&V?

When a card is added to a wallet, the issuer decides how to verify the request: approve silently (low risk), decline, or step up with verification, most commonly a one-time code to the cardholder’s phone or banking app. Each path has a documented attack:

• Real-time OTP phishing. The criminal starts enrollment with stolen card data, the genuine cardholder receives the code, and a phishing page, text, or call harvests it within its validity window: the adversary-in-the-middle mechanics we dissect in this month’s AiTM article. Scaled kits orchestrate the timing so smoothly that victims believe they are stopping fraud, not enabling it.
• Call center social engineering. Where step-up routes through human agents, impersonators armed with breached personal data talk the enrollment through, the same pressure tactics used in impersonation scams.
• Interception of the channel. SIM swaps and call forwarding steal the code without the victim’s participation.
• Silent-path abuse. Cards whose data scores as low risk enroll with no step-up at all; criminals test portfolios to find issuers and card ranges with permissive silent approval.
• Compromised cardholder devices. Malware on the victim’s own phone can read codes and complete enrollments onto attacker-controlled wallets.

The harvested-card markets we describe in our dark web monitoring guide now price records partly on their provisioning success odds, and downstream, provisioned tokens feed the relay operations covered in the Ghost Tap analysis later this series: enrollment is the chokepoint for an entire fraud economy.

What does defense look like on the issuer side?

1. Risk-score the provisioning event itself: device reputation and linkage (how many cards has this device enrolled?), geography versus cardholder footprint, card-data provenance signals, time since card issuance, and enrollment velocity across the portfolio. A phone in one country enrolling its ninth card from another is not ambiguous.
2. Upgrade step-up beyond SMS: in-app approval inside the authenticated banking app, with the enrollment details displayed (which wallet, which device, where), turns the verification into informed consent rather than a relayable code. App-based approval also inherits the phishing resistance argument from our passkey coverage.
3. Tell the cardholder, always: immediate notification on every successful enrollment, naming the device, with a one-tap kill switch. The genuine owner is the fastest fraud detector available.
4. Constrain the newborn token: conservative spending velocity and transaction-type limits for the first days of a new token’s life, relaxed as legitimate behavior accrues. Most provisioning fraud cashes out fast; a slow first week breaks the economics.
5. Close the human path: call-center enrollment assistance deserves the strongest caller verification, not knowledge questions answerable from breach data.

What can merchants and cardholders do?

• Merchants: wallet acceptance remains safer than raw card acceptance, and that stays true. The adjustment is in risk models: treat token freshness as a feature, watch for new-token, high-velocity, resale-friendly purchases, and remember that a wallet cryptogram proves the token, not the shopper’s honesty.
• Cardholders: never read a code to anyone, including your bank; banks do not call asking for codes. Read what the code message says it authorizes before typing it anywhere: provisioning codes say so. Act on wallet-enrollment alerts instantly, and lock down the phone account against SIM swaps.

Frequently asked questions

Isn’t this just normal card fraud?

Same stolen data, different weapon. Provisioning converts a number that works only online into tap-to-pay credentials accepted everywhere, with wallet trust attached. It is the upgrade path that makes modern stolen-card markets profitable.

Does provisioning fraud mean mobile wallets are insecure?

No. Wallet transactions remain cryptographically stronger than any card swipe or typed number. The weakness is the enrollment gate, which belongs to issuer verification, not to the wallet’s payment architecture.

Who eats the loss when a stolen card is provisioned?

Generally the issuer under network rules for fraudulent wallet transactions, which is exactly why issuers invest in provisioning risk engines; merchants following standard acceptance rules are usually protected on these transactions.

How do I know if my card is in someone else’s wallet?

Enrollment notifications and your bank’s card-management screens, which increasingly list active digital tokens per device. Any wallet or device you do not recognize warrants an immediate token kill and card review rather than a wait-and-see.

Can removing my card from my own wallet stop the fraud?

No: the criminal’s token lives on their device, independent of yours. The issuer must suspend that specific token (or the card). Token-level control is the architecture’s saving grace: the plastic can keep working while the fraudulent token dies.

Wallet provisioning fraud is a border problem: the territory inside is well defended, so the fight moved to the checkpoint. Issuers who treat enrollment as a risk decision, verify through channels criminals cannot relay, and keep the cardholder in the loop turn the checkpoint back into what it was designed to be.