Security and fraud concerns are often aligned but sometimes they run counter. The 2017-2022 crypto onramp craze is a great example, and I think we’ll see the same phenomenon with Agentic commerce: Yesterday I asked which of these 4 payment methods had the highest fraud rates to purchase crypto in the US 1. ACH 2. Debit cards 3. Apple/Google Pay 4. Wires Most people guessed ACH or debit cards. But the answer is number 3, Apple & Google Pay wallets. Wallets had the worst fraud despite the best security, for 2 reasons: 1. Wallet tokenization design was built with mostly security in mind and ignored fraud concerns When you add a card to a wallet, its 16-digit card number (PAN) is replaced with a device-specific number (D-PAN). The D-PAN doesn’t keep the card’s first 6–8 digits, the BIN, which merchants use to identify the issuing bank. Each bank’s tokens did get their own new BIN range, so the issuer was still technically identifiable. But merchants had no way to map those new ranges back to a bank name. That broke a common fraud control. Merchants keep blocklists of issuers with weak fraud controls and decline their cards. Without knowing the issuer, those blocklists stopped working for wallet transactions. 2. Wallet tokenization made some fraud velocity checks meaningless The other fundamental issue with D-PAN was that it was device bound. A fraudster could take the same card, add it to 1000s of devices and generate all new D-PANs. Basically, they used the same card over and over but it looked different each time. *** What did we build to counteract these issues? (I promise we'll get to agentic commerce!) It took us several years to get to the bottom of this and countless conversations with Apple, Google, Visa and Mastercard. The solution that we & the industry now use: 1. New tokenization method called M-PAN which is a merchant bound token to prevent a fraudster from creating 1000s of D-PANs from the same card number. 2. Visa created a new API called Payment Account Reference, which lets you identify if two D-PANs are connected to the same PAN. 3. New mapping built from D-PAN BIN ranges to identify issuers, so “issuer name” based rules still work. These solutions are available to our merchants who use us for fraud prevention on wallet transactions. *** The question we’re now asking: what does this mean for Agentic commerce? History is repeating itself. Agentic shopping is essentially introducing a new actor, an Agent, to whom you need to hand over your card. In many ways, an Agent appears like a wallet. We’re very likely to see similar fraud vectors like adding a stolen card to 100s of Agents and generating a new D-PAN for each of them to shop. As Agent builders figure out how to tokenize the consumer’s card, our suggestion would be to use M-PAN over D-PAN. If you need help with all this, reach out. We’re building solutions to these problems at @sardine — more to come this week! — and are here to help and brainstorm.