Your Fraud Rules Were Trained on Humans. Who Are They Declining Now?

For years, ecommerce fraud systems have been asked a familiar question: does this transaction look like something a real customer would do?

That question is getting harder to answer.

A legitimate shopper may now delegate product research, comparison and eventually purchasing to an AI agent. The agent can move through a site faster than a person, arrive at checkout without the browsing trail a human normally leaves behind, use credentials or payment tokens on someone else’s behalf, and create combinations of account, payer and shipping data that once looked like obvious account takeover.

Meanwhile, actual attackers are learning to exploit exactly the same ambiguity.

This does not mean every fraud platform is a collection of brittle rules literally “trained on humans”. Modern systems increasingly use machine learning, network intelligence and hundreds of transaction signals. Stripe, for example, says Radar evaluates hundreds of risk factors and learns from new purchase patterns and merchant feedback. The problem is subtler: many of the behavioural and identity signals historically useful for distinguishing a good shopper from a bad one become less reliable when authorised software starts behaving in ways previously associated with automation, compromise or abuse. [1] [2]

An AI shopping-agent false decline is a legitimate, authorised purchase made or initiated by a delegated AI agent that is incorrectly blocked because a fraud, payment or account-security system interprets the agent’s behaviour as risky.

That definition matters because not every failed order is the same. A merchant fraud engine can block an order before authorisation. An issuer can decline the payment. An account-security system can interrupt the session. A merchant can authorise the payment and then cancel the order during post-payment screening. For measurement purposes, those events should not be thrown into one bucket.

The larger point is this: the next false-positive problem in ecommerce will not be solved only inside the fraud dashboard. Some of the most useful evidence will arrive later, through the support queue.

And that is where Alhena’s perspective becomes interesting. Alhena is not a fraud vendor. It operates on the other side of the decision, in the shopping and support experience, where a customer eventually asks some version of: Why did you decline the order my agent was authorised to place?

The checkout has a new kind of legitimate buyer

Agentic commerce is moving beyond product discovery.

HUMAN Security’s 2026 benchmark found traffic from AI agents and agentic browsers grew 7,851% year over year in 2025. Its data shows 77% of agentic AI activity occurring on product and search pages, but agents were also appearing on account pages, authentication flows and checkout pages: 8.8%, 5% and 2.3% of observed agentic activity respectively. More than 95% of AI-driven traffic in its dataset was concentrated in retail and ecommerce, streaming and media, and travel and hospitality. [3]

For a deeper explanation of how that buying model works, see Alhena’s guide to agentic commerce. The important shift for fraud teams is that software is no longer merely crawling the catalogue. It can increasingly participate in the transaction.

That changes what “normal” looks like.

Signifyd now explicitly identifies agentic commerce as a source of ecommerce false declines. It notes that rapid, sequential or cross-category purchases made by an agent can resemble a compromised account to a rules-based system, causing legitimate agent-led or agent-placed orders to be rejected. Its recommendation is equally revealing: pass information about the agent, its permissions and the session into the fraud stack rather than forcing the risk system to infer intent from behaviour alone. [2]

Visa has acknowledged the same structural problem from another direction. When it introduced Trusted Agent Protocol, it said merchants face bot-detection systems that can mistakenly block legitimate agentic transactions. The protocol is designed to let a recognised AI agent prove its identity and associated authorisation cryptographically rather than asking the merchant to infer whether automation is benign from browsing behaviour. [4] [5]

Mastercard has moved even closer to the authorisation layer. In September 2026, it announced an Agent Pay trust service that combines identity, intent, behavioural and fraud signals, including a probability score estimating whether a transaction was initiated by an AI agent. Mastercard says the additional context is intended to help issuers approve legitimate agent-led purchases with less unnecessary friction. [6]

That tells us something important.

The better questions are:

Who is the agent? Who authorised it? What was it authorised to do? Does this transaction fit that mandate? And has anything changed since permission was granted?

Legitimate agents and attackers are converging on the same signals

The uncomfortable part of this transition is that better recognition of legitimate agents cannot simply mean becoming more tolerant of automation.

Attackers are adapting too.

In Akamai’s 2026 Securing the Agentic Storefront report, RH-ISAC Chief Security Officer and VP of Strategy Pam Lindemoen describes agentic commerce as a “signal masking” problem. Security systems have historically used digital fingerprints and behavioural patterns to distinguish humans from bots. AI shopping agents complicate that distinction because legitimate automation can increasingly reproduce behaviour associated with genuine customers. [7]

At the same time, Lindemoen points to synthetic identity fraud in which criminals combine legitimate and fabricated information to build what the report calls “Frankenstein” accounts. Those accounts can be cultivated so that they resemble established, trustworthy customers rather than disposable fraud identities. Akamai’s wider argument is that static defences are increasingly inadequate and that detection, response, recovery and shared telemetry need to operate as a continuous loop. [7]

The threat is not hypothetical at account level either. HUMAN says post-login account-compromise attempts more than quadrupled in 2025, reaching an average of roughly 402,000 attempts per organisation in its dataset. More strikingly, HUMAN says only half a percentage point separated the rate of benign from malicious automation across interactions analysed by its platform. Its conclusion is that the old binary distinction between a bot and a non-bot no longer captures the important question: intent. [3] [8]

That produces two failures that can happen simultaneously:

This is why simply loosening fraud rules for anything labelled “agentic” would be as dangerous as blindly blocking it.

There is already a trust problem around that ambiguity. Sift’s Q4 2025 Digital Trust Index found 47% of consumers were worried about AI agents making unauthorised purchases. In the same research, 61% said they would blame the AI company when something went wrong, while 39% would blame the merchant. [9]

And an often-repeated Accenture statistic needs to be stated precisely: its 78% figure refers to financial payments leaders, not consumers. Accenture reports that 78% of financial payments leaders expect fraud to increase significantly with agentic payments; 60% said they did not have a dedicated response plan with forensic tools for agent-driven fraud. Accenture highlights agent impersonation, prompt manipulation, synthetic identities and machine-speed fraud among the emerging risks. [10]

So merchants are being squeezed from both directions. Decline too aggressively and they may reject authorised agent purchases. Relax too aggressively and they may make it easier for hijacked agents, synthetic identities or automated fraud to blend into legitimate traffic.

That is the new false-decline problem.

The helpdesk is where false declines become visible

Fraud teams see a risk decision.

Support teams often see what happened next.

That difference is more important than it sounds.

Suppose a shopper tells an AI agent to buy a particular pair of shoes under £150. The agent signs in, selects the right size, uses an authorised payment credential and submits the order. The merchant cancels it because the device, browsing sequence or identity combination looks unusual.

In the fraud system, that may remain a successful block.

In the customer’s world, it is a failed purchase.

Two hours later, support receives:

“Why did you cancel this? I told my shopping agent to order it.”

Or:

“The payment is mine. The shipping address is my daughter’s.”

Or:

“Your site rejected the agent, so I bought the same item myself five minutes later.”

The final message contains information the original risk model did not have when it made the decision.

This is not just a thought experiment about how support could contribute. A 2024 Datos Insights study, based on interviews with 200 mid-size and large US and UK ecommerce merchants conducted between July and September 2023, found that merchants already use downstream signals to identify conventional false declines. The sample carried a seven-point margin of error at the 95% confidence level.

Among merchants in the study that tracked false declines, 28% of US merchants and 33% of UK merchants used inbound customer contact — calls, emails or other communications following a decline — as one way of identifying them. Datos explicitly argues that because this evidence arrives in the call centre or operations organisation, fraud teams need to partner with those teams and collect the data to improve fraud-system performance.

That is remarkably close to the operating model agentic commerce now needs.

Alhena has previously written about the strange support tickets AI shopping agents can create: account names that do not line up neatly with the payer, purchaser and recipient; shoppers who do not immediately recognise an agent-initiated order; and support agents trying to establish whether an action was actually authorised.

That article looks at those situations ticket by ticket.

The next step is to stop treating them as isolated curiosities and turn them into structured false-positive telemetry.

There is an important caveat: a customer saying “that transaction was legitimate” is not by itself ground truth. First-party abuse exists. Social engineering exists. Accounts can be compromised after a genuine login. A support ticket should therefore be treated as evidence to investigate, not an automatic instruction to override a fraud decision. Akamai and HUMAN’s findings on synthetic identities and post-login compromise make that distinction especially important. [7] [3]

But once a transaction is independently validated — through re-authentication, mandate evidence, a successful subsequent transaction, analyst review or another reliable outcome — the support interaction becomes valuable training and tuning data.

The metric missing from the fraud dashboard

False declines are not a new ecommerce problem.

What is new is the need to isolate the subset caused by delegated buying.

Datos Insights estimated an industry-average ecommerce false-decline rate equivalent to 1.51% of annual ecommerce sales, translating in its model to roughly US$175 billion in lost global ecommerce sales in 2024 and US$265 billion by 2027. Those figures are estimates, not measured agentic-commerce losses, and the underlying merchant interviews pre-date today’s wave of shopping agents. They are useful here as evidence of the scale of the existing false-positive problem, not as an estimate of AI-agent impact.

The same study also illustrates why businesses should be wary of intuition. Fifty-three per cent of surveyed merchants believed their false-decline rate was below 1%, while Datos calculated that only 34% actually fell below that threshold; 44% had calculated rates above 3%, although only 12% thought their rate was that high.

As of October 2026, the public sources reviewed for this article do not provide a credible cross-merchant benchmark for one more specific question:

What percentage of legitimate AI-agent purchase attempts are falsely declined or cancelled?

That is the number the industry now needs to build.

For an ecommerce brand, the first measurement layer could look like this:

The denominator matters. So does the owner of the decision.

A merchant-side fraud block should not be mixed with an issuer decline. Neither should be silently combined with a post-authorisation order cancellation, an account lockout or a failed authentication challenge. Otherwise the brand may tell its fraud vendor to fix an issuer problem, or tell its payments team to fix an account-security rule.

Every event should therefore carry a decision layer and, wherever possible, a decision reason.

For delegated transactions, add another dimension:

agent involved: yes / no / unknown.

“Unknown” is essential. Until trusted-agent identification becomes widespread, plenty of agentic traffic will be invisible or probabilistic. Mastercard’s decision to introduce an explicit probability score for AI-initiated transactions and Visa’s work on cryptographic agent recognition show why this distinction is becoming infrastructure rather than analytics trivia. [6] [5]

Build the support-to-fraud feedback loop

Once the metric exists, the operating model becomes straightforward.

Capture the original decision. Store the transaction or order identifier, risk decision, decision owner, decline or cancellation reason, timestamp and available risk metadata. Do not reduce every failed payment to “declined”.

Capture the agent context. Where it is available, retain which agent initiated the action, whether the agent was recognised, what account it acted for, the relevant session identifier and any evidence describing the user’s mandate or limits. Signifyd specifically recommends passing agent identity, permissions and session metadata into fraud tools. Visa’s Trusted Agent Protocol likewise centres agent identity and associated user authorisation. [2] [5]

Tag the recovery conversation. Support needs structured dispositions such as agent_authorised_confirmed, agent_not_authorised, human_retry_succeeded, order_restored, fraud_confirmed, issuer_decline, merchant_risk_block and unable_to_determine. The exact taxonomy will vary, but the point is to make the outcome queryable rather than burying it in free-text notes.

This extends the recommendation from Alhena’s existing article on agent-originated support tickets: make agent traffic visible in the support stack instead of waiting until volume is high enough to become obvious.

Validate before relabelling. A ticket saying “I authorised this” should trigger verification, not instant approval. The goal is not to teach a fraud system that complaints equal legitimacy. The goal is to create a high-quality labelled outcome after support, payments, security or fraud operations have established what happened.

Send the outcome back. Fraud systems improve when businesses return reliable outcome data. Stripe’s documentation explicitly notes that merchants can have additional information because of later customer interactions and says feedback contributes to more accurate risk evaluations. Stripe also measures false-positive rate and recall through controlled model experiments. [1]

Sift describes a similar feedback model: merchants can send manual-review outcomes through its Labels API, and its documentation recommends continuous feedback so scores can adapt to the merchant’s observed good and bad behaviour. [12] [13]

This is where Alhena fits naturally — not as another fraud-decision engine.

Alhena’s AI Support Concierge is designed to operate across customer-support workflows involving orders, returns, account questions, escalations and commerce actions. The opportunity in an agentic-fraud world is for the support layer to preserve the context that arrives after an upstream decision: what the shopper says was authorised, what happened to the order, whether a retry succeeded and what resolution ultimately occurred.

That context should then move to the system that owns the fraud decision.

In other words:

That feedback loop is more useful than asking support to become a shadow fraud department.

Do not solve the problem by allowlisting AI agents

There is an attractive but dangerous shortcut here:

Just recognise the big shopping agents and let them through.

That solves the wrong problem.

Knowing that software is operated by a legitimate agent provider does not prove that this particular action is legitimate. A trusted agent can still be operating on a compromised account, carrying manipulated instructions or acting outside the customer’s intended scope. Akamai explicitly highlights agent hijacking and synthetic identity fraud as risks in the new commerce environment. [7]

A safer model separates four questions:

Agent identity: Is this really the agent it claims to be?

Human authority: Which customer authorised it to act?

Mandate: What exactly was it permitted to buy, for how much, for whom and under what conditions?

Transaction risk: Does this particular action still make sense given the account, credential, merchant and transaction context?

The payments ecosystem is beginning to build those layers explicitly. Visa’s Trusted Agent Protocol uses cryptographic signatures to help merchants verify recognised agents and user authorisation. Mastercard’s Agent Pay framework brings together identity, intent, controls, execution and fraud intelligence, and its new agentic signals are designed to distinguish ordinary agent-led activity from situations requiring additional checks. [5] [6]

This is the deeper connection between agentic commerce and the work ecommerce teams are already doing around machine-readable product information.

Brands investing in AEO optimisation for ecommerce are making products, policies and brand knowledge easier for AI systems to understand.

Checkout needs the complementary capability:

Without the second half, brands risk building beautifully agent-readable catalogues that send high-intent delegated shoppers into a checkout designed to distrust them.

What Alhena can responsibly say today

There is a tempting version of this article that claims ecommerce brands are already losing some dramatic percentage of agent-generated revenue to false declines.

The evidence does not support that claim yet.

Public research establishes four things with reasonable confidence.

First, agentic traffic is growing quickly and is reaching accounts, authentication and checkout, not merely product pages. HUMAN measured 7,851% year-over-year growth in agentic AI traffic in 2025 and observed activity across each of those commercially sensitive surfaces. [3]

Second, fraud specialists are already seeing the false-positive problem. Signifyd explicitly identifies legitimate agent-led orders being incorrectly declined when agent behaviour resembles account compromise, while Visa says conventional bot detection can mistakenly block legitimate agentic transactions. [2] [4]

Third, the opposite risk is equally real. HUMAN is observing sharply higher post-login compromise activity, while Akamai and RH-ISAC describe agent hijacking, signal masking and synthetic identities that can make malicious activity appear trusted. [3] [7]

Fourth, customer support is already an established source of false-decline evidence. Datos Insights found that a meaningful share of merchants tracking false declines use inbound customer contact as a detection method and specifically recommended collaboration between fraud and operations teams.

What we do not yet have is a reliable network-level number for AI shopping-agent false declines.

Alhena should not manufacture one.

Its more defensible position is also the more useful one: support is an underused sensor for measuring this transition.

Alhena’s earlier piece on AI shopping agents and the support tickets they create focused on what individual delegated-shopping failures may look like. The next operational step is to connect those tickets to orders, risk decisions, recovery outcomes and fraud-vendor feedback.

That creates the dataset from which a real benchmark can eventually emerge.

The companies that learn fastest will not necessarily be the ones with the loosest fraud rules or the harshest ones.

They will be the ones that can tell the difference between automation and authority.

And when they get that distinction wrong, they will know where to look.

Not only at the decline log.

At the customer who came to support to tell them the decline was a mistake.