Digital wallet transactions -- payments processed through Apple Pay, Google Pay, BNPL instruments, and proprietary wallet products -- have grown to represent a significant share of digital payment volume. They also have a fraud risk profile that is materially different from traditional card-not-present transactions. Fraud controls built around the CNP risk model -- BIN-based risk scoring, card velocity, AVS checks -- miss the patterns that are specific to wallet-funded payments.
Why wallets change the fraud surface
Traditional card-not-present fraud involves a stolen card number. The attacker has the PAN, the CVV, and in many cases the billing address, obtained through a data breach or carding operation. Fraud controls built around this threat model check that the card data is consistent with the issuer's records and that the transaction velocity is within normal bounds.
Digital wallet transactions abstract away the underlying card. The merchant receives a payment token, not the card PAN. This tokenization is a security feature that eliminates the risk of card number theft at the merchant layer -- but it shifts the fraud surface to the wallet account itself. The question is no longer "is this card number stolen?" but "has this wallet account been taken over?"
Wallet account takeover has a different mechanism and different detection signature than card number theft. The attacker obtains wallet account credentials through phishing, credential stuffing, or social engineering. They log in as the legitimate user, and because the wallet contains valid linked payment methods, every transaction they initiate carries the real user's valid tokenized credentials. AVS checks pass. CVV checks pass. The card is valid because the card is real -- it is the wallet session that is fraudulent.
The fraud patterns specific to digital wallets
Wallet provisioning fraud
Wallet provisioning is the process of adding a card to a wallet. An attacker who obtains a card number can provision it to their own wallet, effectively linking a stolen card to a device and wallet account they control. Once provisioned, the card transacts through the wallet's token -- the original card number is no longer directly involved in the transaction, which can make card-level fraud signals less effective.
Provisioning fraud detection requires monitoring the provisioning event itself, not just the subsequent transactions. Signals include: provisioning from a new device that has no prior wallet history, provisioning of a card that has been declined recently at the issuer level, and provisioning volume from a single device within a short window.
Wallet balance manipulation and P2P abuse
Platforms with internal wallet balances -- stored value that users fund and transfer -- have a distinct fraud pattern around balance manipulation. The attack typically involves funding a wallet with a stolen payment method, transferring the balance to another wallet (which may be the attacker's own or a mule account), and then withdrawing. The chargeback comes back from the original stolen card; the transferred balance is gone.
This is an ACH-push fraud pattern applied to wallet infrastructure. Detection requires treating wallet funding events and peer transfers as first-class fraud signals, not just monitoring the eventual withdrawal. A wallet that is funded and immediately transferred to a new recipient is a high-risk pattern regardless of how the underlying transaction fields look.
Authorized push payment fraud using wallet rails
Authorized push payment fraud is a category where the legitimate account holder is manipulated into initiating the fraudulent payment themselves. The attacker poses as a bank, a government agency, or a trusted institution and convinces the user that they need to transfer funds immediately. The user initiates the transfer from their wallet account; the transfer is technically an authorized transaction by the legitimate user.
APP fraud is difficult to detect at the transaction level because the user's authentication is genuine -- they really did initiate it. The signals are behavioral: the recipient is a new counterparty the sender has never transacted with, the amount is unusually high relative to the sender's history, and the transaction was preceded by a series of authentication events (possibly including a phone call that was not logged by the platform). These are the patterns that behavioral scoring can see; rules operating on the transaction fields alone cannot.
What detection requires
Effective wallet fraud detection adds three requirements to a standard payment fraud stack:
Provisioning event monitoring: Treat card provisioning as a transaction that deserves its own risk score, not just an account setup step. The risk signals at provisioning time (device reputation, account age, card history) are often more predictive than anything available at transaction time.
Counterparty graph analysis: For P2P and wallet transfer patterns, the recipient is a key signal. Has this recipient received funds from many different senders in a short period? Is this a new wallet account with no prior receipt history? The counterparty graph for the recipient matters as much as the sender's account history for detecting money mule activity.
Behavioral session context: The session immediately preceding a wallet transfer -- how long was the user on the platform, what actions did they take, was there any unusual authentication activity -- is the primary signal for APP fraud. This requires session-level data ingestion that goes beyond transaction fields.
Riskgrove's scoring API accepts wallet transfer context fields (sender_wallet_id, recipient_wallet_id, funding_method, session data) and returns a risk score that incorporates counterparty graph signals and session behavioral context. For platforms processing digital wallet volume, we recommend including these fields in your scoring integration to capture the wallet-specific fraud patterns that transaction-field scoring alone misses.