You've seen the headlines about AI agents making purchases. Your board has asked about agentic commerce. And somewhere in your organization, someone has already decided what it means for your fraud controls.
Most of those assumptions are wrong.
The gap between what people think agentic commerce requires and what it actually demands creates real compliance risk. Here's what your fraud team needs to know right now.
Why These Myths Persist
Agentic commerce sits at the intersection of AI capabilities, payment infrastructure, and regulatory frameworks. When Visa and Mastercard unveiled platforms designed to give AI agents purchasing power, the industry started filling knowledge gaps with assumptions. Some came from misunderstanding payment protocols. Others stemmed from confusion about liability in AI-driven transactions.
The result: fraud teams are preparing for the wrong problems.
Myth 1: Agentic Commerce Requires New Payment Rails
Reality: The settlement process remains unchanged.
Your existing payment infrastructure handles agentic transactions the same way it processes card-not-present purchases today. Google's Agent Payments Protocol (AP2), an open-source framework enabling merchant-agent interaction, doesn't alter how funds move between accounts. Neither do competing protocols from other providers.
What changes is the front-end layer. You need infrastructure that lets AI agents initiate transactions, but the back-end payment flow stays the same. As Matthew Gaughan of Javelin Strategy & Research notes, "The payment itself is handled normally on the merchant's back end."
This matters for fraud teams because your existing transaction monitoring rules, velocity checks, and authorization controls still apply. You're not building a parallel fraud detection system. You're extending your current one to handle a new initiation channel.
Myth 2: Liability Falls to the AI Provider
Reality: Merchants and payment service providers retain responsibility for settlement, refunds, chargebacks, and compliance.
OpenAI's developer documentation makes this explicit: merchants own the payments associated with agent transactions. When an AI agent completes a purchase, your merchant clients carry the same chargeback risk they face with any card-not-present transaction.
For fraud risk managers, this creates a familiar problem with a new vector. You're not dealing with a customer who mistyped a shipping address. You're managing disputes where an AI agent misinterpreted instructions or selected the wrong product.
The challenge: your current dispute resolution workflows assume human decision-making at every step. When a customer claims "I didn't authorize this," you can review their account activity, verify their identity, and assess intent. When an AI agent made the purchase, who do you authenticate? The agent's owner? The agent itself? The platform hosting the agent?
These questions remain unresolved across the industry. "They're all trying to draw lines in the sand, but I don't think any of them truly know where it's going to end," Gaughan said.
Myth 3: Your Current KYC Controls Cover AI Agents
Reality: You can't perform Know Your Customer due diligence on a non-customer entity.
Your AML program identifies beneficial owners, screens against sanctions lists, and monitors for suspicious patterns tied to human behavior. AI agents don't fit this model. They're not account holders or politically exposed persons.
What you need instead: Know Your Agent's Principal (KYAP). This means authenticating that the human authorizing the agent has legitimate control, verifying the agent operates within defined mandates, and monitoring for manipulation attempts.
AP2's mandate system provides a starting point. Mandates verify that an agent followed user instructions, creating an audit trail you can review when transactions look suspicious. But mandates don't solve the authentication problem. You still need to confirm the human behind the agent is who they claim to be and that they authorized the agent's actions.
Myth 4: Fraud Detection Models Will Adapt Automatically
Reality: Your machine learning models trained on human behavior will flag agent transactions as anomalies.
Consider your typical velocity rule: five transactions in ten minutes from the same card triggers a fraud alert. An AI agent comparison-shopping across merchants could easily hit that threshold while performing exactly as instructed.
Your behavioral models look for patterns like:
- Purchase timing (humans don't buy at 3 AM unless something's wrong)
- Product combinations (certain item pairings signal fraud)
- Navigation patterns (fraudsters move through checkout differently than legitimate customers)
AI agents break all these assumptions. They transact at any hour. They compare prices across merchants in seconds. They follow optimized paths through payment flows that no human would take.
You'll need separate risk models for agent-initiated transactions, or at minimum, a reliable way to identify and segment them. That requires merchants to flag agent transactions at the protocol level, which means you need visibility into which agentic platforms your merchant clients support.
Myth 5: This Is a Future Problem
Reality: Your merchant clients are evaluating integrations now.
Multiple agentic commerce protocols exist today. Your merchants are receiving pitches from platform providers. Some are already planning integrations. If you wait until agentic transactions appear in your fraud queue to build detection capabilities, you're responding to incidents instead of preventing them.
Start by identifying which merchants in your portfolio are most likely to adopt agentic commerce early. E-commerce merchants, subscription services, and businesses with high repeat-purchase rates are obvious candidates. Then map their integration timelines against your fraud infrastructure roadmap.
You don't need to solve every problem immediately. You need to know which problems you'll face first.
What to Do Instead
Begin with education, not implementation. Understand how competing protocols work and what they require from payment service providers. Google's AP2 framework is open-source; review its technical specifications to see how mandates function and what data you'll receive about agent transactions.
Then assess your infrastructure's interoperability. Gaughan notes that banks "probably will require them to overhaul some of their internal systems to be more interoperable and accessible through APIs." Your fraud detection systems need API access to agent transaction metadata, mandate details, agent identifiers, principal authentication records, that doesn't exist in traditional payment messages.
Finally, document your liability assumptions in writing. When an agent transaction results in a dispute, which party in your processing chain carries responsibility? Get those agreements in place before the first chargeback arrives.
Agentic commerce introduces genuine complexity, but most of that complexity stems from unresolved industry questions, not technical barriers. Your fraud controls work. You just need to extend them to a new transaction type without inventing capabilities you don't yet need.
