Agentic Commerce Fraud and the Four-Party Card Model: Who Bears the Loss When an AI Agent Pays?

The card system was built for a person at a checkout. Autonomous AI agents change that assumption, and the four-party model has no clean answer yet for who pays when an agent’s purchase goes wrong. This guide walks through the model, the new fraud surface that agents create, and what a Know Your Agent layer adds for fraud and risk teams at issuers, acquirers, payment service providers and merchants.

For decades, card fraud controls rested on one quiet assumption: a human decides, a human clicks and the system can observe that human. Device fingerprints, typing rhythm, mouse movement and session history all feed risk engines on that assumption. When a software agent buys on a user’s behalf, most of those signals disappear. The agent runs on a server, it has no mouse and its session looks nothing like a shopper’s.

Industry players have noticed. OpenAI and Stripe launched the Agentic Commerce Protocol. Google introduced the Agent Payments Protocol, known as AP2. Card networks have announced their own programs for agent-initiated payments, and identity vendors have started to sell Know Your Agent products. These efforts matter, because they build the pipes. However, pipes do not decide which agents deserve trust, and they do not settle who bears the loss when something breaks.

This article focuses on that gap. It starts with a short refresher on the four-party model, then shows how agents strain each part of it. In addition, it lists the new fraud scenarios that follow, and it explains what a behavioral trust layer adds. It also keeps a clear view of limits. The Agent Trust Score covers agents and wallets on public chains, and card-only ecosystems need their own behavioral data. Moreover, the design lessons still transfer, and they help risk teams plan today.

A Short Refresher: The Four-Party Model

Card payments involve four parties, and a card network connects them.

• Cardholder: pays for goods or services with a card.
• Merchant: sells the goods or services and accepts the card.
• Issuer: the cardholder’s bank. It extends credit, approves or declines each transaction and bears the credit risk.
• Acquirer: the merchant’s bank or processor. It accepts card transactions on the merchant’s behalf and settles funds to the merchant.

The card network sits between issuer and acquirer. It sets the rules, routes messages and runs dispute processes. Payment service providers often sit between merchants and acquirers, so that small merchants can accept cards without dealing with banks directly.

How a Transaction Flows

A typical online card payment moves through four stages. The cardholder submits card details at checkout. Furthermore, the merchant or its payment provider sends an authorization request through the acquirer and the network to the issuer. The issuer runs its own fraud and credit checks and returns an approval or decline. Later, clearing and settlement move the money between banks.

Fraud controls act at several points in this flow. Merchants screen orders before they send them. Acquirers and payment providers add their own scoring. Issuers make the final call using their own models, which draw on the cardholder’s history. Networks add rules and shared intelligence. Each party sees a different slice of the evidence.

How Liability Works

Liability follows a long-standing logic. The party best placed to stop a fraud usually carries the loss. Authentication tools such as 3-D Secure shift liability toward the issuer when the cardholder is verified, because the issuer took part in the check. A card-not-present fraud that slips past the merchant often lands on the merchant as a chargeback. Disputes follow network rules, and evidence from each party decides the outcome.

This system works because the parties can observe the cardholder. The issuer knows the customer’s history. Likewise, the merchant sees the session. The network sees patterns across millions of transactions. Every control assumes that someone could verify a human, and that assumption now faces strain.

What Agentic Commerce Changes

In agentic commerce, a software agent chooses what to buy and completes the purchase on the user’s behalf. McKinsey estimates that agent-mediated commerce could reach between $3 trillion and $5 trillion globally by 2030. Even if the real number lands lower, the direction is clear: a growing share of purchases will start with an agent and not with a person at a screen.

The New Rails

Several efforts build the rails for these purchases.

The Agentic Commerce Protocol. OpenAI and Stripe launched a protocol that lets an agent pay through a shared payment token, without exposing raw card details. Payments Journal described the launch as an effort to make agent checkout safe and standard.

AP2. Google’s Agent Payments Protocol uses verifiable credentials and signed mandates to record what a user asked for and approved. Its announcement describes it as an extension of existing agent communication standards.

Network programs. Visa and Mastercard have each announced programs for agent-initiated payments. A report on the Visa and OpenAI partnership shows how networks and AI companies are moving together. Beyond that, a commentary on liability describes Mastercard’s approach as using signed requests so that merchants can recognize trusted agents.

Identity frameworks. Trulioo describes a Digital Agent Passport that carries an agent’s origin, legitimacy, authorization and consent, and its Know Your Agent explanation frames the idea for payments.

What the Rails Solve and What They Leave Open

These efforts solve real problems. Tokens keep card numbers out of agent hands. Credentials let merchants recognize registered agents. Mandates record what a user allowed. Each of these is a building block of safe agent commerce.

None of them, however, answers the risk question: how likely is this agent, and the operator behind it, to cause a loss? A valid token shows a payment route. At the same time, a valid credential shows registration. A signed mandate shows permission. Notably, a bad operator can hold all three. Fraud teams therefore need a further layer of evidence.

The Lost Signal

Fraud models for card-not-present traffic lean heavily on signals about the person. Risk engines read a long list of them.

• Device fingerprint. Browser, operating system, screen size and installed fonts identify a returning device.
• Behavioral biometrics. Typing cadence, mouse paths and touch pressure distinguish a human from a script.
• Session history. Pages visited, time on page and cart changes show how a real shopper behaves.
• Location and network signals. IP address, geolocation and network type support or contradict the stated address.
• Account history. Past orders and returns build a profile that the issuer and merchant both use.

A server-side agent produces almost none of these. It has no mouse, no typing and no browser in the human sense. Its network address may belong to a cloud provider. One payments analyst describes the effect as “a total loss of the traditional fraud signal” in a liability deep dive. The piece is opinion rather than settled rule, but the underlying mechanics are easy to verify. A risk model that relied on typing rhythm has nothing to read when no one types.

The Trade-Off Risk Teams Face

The lost signal forces a trade-off. If a risk engine cannot tell a legitimate agent from a bot attack, it can decline agent traffic or accept it blindly. Declining hurts good customers and gives up a growing channel. Accepting invites fraud and may leave the merchant holding the loss.

Neither choice scales. A third path exists: replace the lost human signals with signals that describe the agent. Three families of such signals are emerging.

1. Authorization signals. Did the user grant this agent this scope? Signed mandates answer this.
2. Credential signals. Is the agent registered and verified? Passports, tokens and network credentials answer this.
3. Behavioral signals about the agent and its operator. How does the agent act, who funds it and how many siblings does it have? This family is where fraud teams have the least tooling today.

The first two families prove permission. In practice, the third estimates risk, and risk is what the fraud team ultimately manages.

The Fifth Participant

Commentators describe the agent as a fifth participant in the four-party model. It is not a cardholder, a merchant, a bank or a network. Yet it sits between the cardholder and the merchant, and it influences every decision. It chooses the product, picks the merchant and triggers the payment.

The liability deep dive argues that the merchant of record is likely to carry the loss by default. In addition, the reasoning is simple. The merchant is the visible seller and the party named in a dispute. When an agent buys something the cardholder did not want, the cardholder disputes the charge, and the chargeback reaches the merchant.

This is analysis and opinion. It is not settled rule. Networks, acquirers and regulators are still working out liability for agent-initiated transactions. Rules may differ by network, by region and by the protocol that carried the payment. The planning assumption for risk teams is nonetheless clear. Until rules say otherwise, expect chargebacks to land with the party closest to the merchant, and expect disputes to be harder because intent is harder to prove.

Why Intent Becomes the Central Question

In a human purchase, intent is rarely in doubt. The cardholder clicked and typed. In an agent purchase, a chain of delegation separates the cardholder from the act. The user told an assistant to buy something. Moreover, the assistant chose a product and a merchant. A payment protocol carried the request.

When the user later disputes the charge, three questions arise. Did the user authorize this purchase? Furthermore, did the agent follow the instruction? Did someone tamper with the agent? Each question needs evidence, and the evidence lives in different places. Signed mandates help with the first question. Agent logs help with the second. Integrity checks and behavioral monitoring help with the third.

New Fraud Scenarios

Agentic commerce adds specific failure modes beyond ordinary card fraud. The list below describes six of them, and each comes with a defensive idea.

Agent Impersonation

A fraudulent agent claims to act for a legitimate user. Without strong binding between the agent and the user, the merchant sees a valid token and little else. An attacker who steals a token or who tricks a user into delegating can use it at many merchants within minutes.

Defense: Bind tokens to specific agents and merchants, use short expiry times and require signed requests that tie the call to a registered agent.

Mandate Abuse

An agent acts outside its granted scope, for example by exceeding an amount, choosing a different merchant category or repeating a purchase. Signed mandates reduce the risk, but only when the merchant or payment provider checks them.

Defense: Verify mandates at authorization time, compare amount, merchant and time with the signed scope and decline or step up when the request falls outside it.

Agent Drift

The same liability analysis describes agent drift. An agent gradually changes behavior as its instructions, tools or underlying model change. It remains technically authorized, yet it acts in ways the user did not intend. Drift produces disputes without clear fraud, which is a hard category for dispute teams.

Defense: Track each agent’s behavior over time, flag changes in spend, merchants or timing and ask for re-authorization after large shifts.

Fleet Abuse

An operator runs many agents that look independent. Each makes small, plausible purchases. Together they exploit promotions, refund policies or reseller margins. Fleet abuse is hard to see transaction by transaction, because each transaction looks normal.

Defense: Aggregate velocity, spend and refund rates by operator and by shared funding source, and treat linked agents as one risk unit.

Friendly Fraud With an Agent Alibi

A buyer disputes a legitimate purchase and claims that the agent bought it by mistake. Dispute teams lack evidence standards for this claim. Without logs of the instruction, the mandate and the agent’s reasoning, the merchant cannot tell a true error from an opportunistic dispute.

Defense: Store mandates, instructions and decision logs for every agent transaction, and make them part of the dispute evidence package.

Compromised or Malicious Agents

An agent built on weak code or steered by a hostile prompt can make harmful purchases. The user’s authorization exists, but the action does not reflect the user’s wishes. This scenario blends security and fraud, and it will grow as agents read untrusted web content.

Defense: Combine integrity checks with behavioral monitoring, and cap what any agent can do without fresh human confirmation.

What a Behavioral Trust Layer Adds

Most of the scenarios above share one feature: the useful evidence sits outside the transaction. It concerns the agent’s operator, its funding and its history. A behavioral trust layer produces exactly that evidence.

The Agent Trust Score

ChainAware’s Agent Trust Score does this for ERC-8004 agents on public chains. It scores the owner wallet’s fraud probability, the feeder address that funded the owner and the creator’s rug pull and honeypot record. Fleet-level farm detection adds a view across agents. The output is a 0 to 1,000 score, five tiers from Untrusted to Sovereign and named flags. Likewise, the score is available through an API and through the Prediction MCP, so that software can call it before it acts.

The evidence maps to the scenarios in the previous section. Beyond that, the owner’s fraud probability and the creator’s record help against malicious operators. The feeder helps against impersonation and laundered credibility. Fleet detection helps against fleet abuse. Tier changes over time help against drift.

What the Public Data Shows

For the registry as a whole, the numbers are sobering. In the launch analysis of 274,792 ERC-8004 agents, 51.8% sat in the two lowest tiers, and 21.1% carried the farm flag. The tier split was Sovereign 20.9%, Trusted 12.7%, Provisional 14.6%, Elevated Risk 25.8% and Untrusted 26.0%. At the same time, the launch article lists the full breakdown.

By Week 41 of 2026, the index held 568,590 agents, and the median trust of that week’s new registrations had fallen to 101, the lowest since tracking began. The Week 41 tracker has the full picture, and the companion article on agent fraud patterns from the tracker explains what the weekly series reveals about concentration, farms and funding.

Payments teams should draw a direct lesson. Cheap identities scale faster than trust. If a registry with open registration produces this mix, any agent ecosystem without behavioral scoring will face the same dynamics.

An Honest Limit

The Agent Trust Score covers on-chain agents and wallets. A card-network agent that never touches a public chain falls outside it. Closed ecosystems hold their own behavioral data, and the scoring of that data belongs to the network, the issuer or the platform. The design principle still transfers: judge the operator, its funding and its fleet, not just the paperwork. As stablecoin settlement and wallet-based agent payments grow, the on-chain layer will move closer to payments risk stacks.

Mapping Agent Evidence to the Four-Party Model

Each party in the card chain faces a different exposure, and each needs different evidence. The table below summarizes the picture.

Party	Main exposure	Useful agent-level evidence
Issuer	Approving a purchase it cannot link to a human	Credential status, mandate presence, operator risk tier
Acquirer and PSP	Onboarding merchants that accept agent traffic	Agent traffic mix, fleet concentration, tier distribution
Merchant	Chargebacks, promotion abuse and fulfilment of bad orders	Agent tier at checkout, farm and funding flags
Card network	Rule gaps and systemic fraud patterns	Cross-merchant fleet patterns and registry-level data
Agent operator	Liability for the agent’s acts	Own score, audit trail of mandates and actions

Each party needs different evidence, but all of it describes the agent and its operator. Notably, the sections below describe what each party can do now.

Issuers

Issuers decide whether to approve each authorization request. When the request comes from an agent, the issuer loses the human signals it normally reads. It can ask for the agent credential and the mandate in the authorization message where networks support them, and it can tune decline and step-up rules for agent-flagged traffic.

Issuers can also build a view of the operators behind agent transactions. When one operator generates many small purchases across many cards, the pattern deserves attention. A shared behavioral score for operators, whether built in-house or sourced from a provider, helps the issuer separate honest assistants from fleets.

Acquirers and Payment Service Providers

Acquirers and PSPs onboard merchants and manage their risk. They can tag agent traffic, track chargeback rates by agent channel and set conservative limits for merchants that start to accept agent checkout. In practice, they can also require merchants to log mandates and credentials, because that evidence supports disputes later.

Acquirers face a portfolio view. If a growing share of a merchant’s volume comes from a handful of operators, concentration risk rises. A fleet-level report helps the acquirer see that concentration before a loss.

Merchants

Merchants carry the visible liability. They can require a credential for agent checkout, verify mandates and attach a behavioral tier to each agent order. In addition, they can set order limits by tier and treat unusual repeat purchases from one operator as a fleet signal.

Merchants also gain from clear policy. A published agent policy tells operators what the merchant requires, which saves disputes. Moreover, a merchant that asks for credentials, mandates and a minimum tier attracts honest agents and deters low-effort abuse.

Card Networks and Standards Bodies

Networks can define liability for agent flows, publish agent authentication specifications and share fleet-level signals across members. Standards bodies can agree on credential formats so that merchants do not need to read a different format for each agent. Both groups can help create evidence standards for disputes that involve agents.

Agent Operators

Operators sit in the fifth seat. They carry responsibility for what their agents do. Operators can keep clean funding structures, keep full logs of instructions and mandates and monitor their own agents for drift. An operator with a strong record earns better treatment from every other party.

A Scenario Walk-Through

The scenario is invented to show how the pieces fit. It does not describe a real transaction.

A shopper tells an assistant agent to renew a software subscription and to buy a replacement laptop battery if it costs under a set amount. The agent holds a payment token and a signed record of the instruction. It visits a merchant and attempts a purchase.

The merchant’s PSP sees a valid token and a signed record. In a human flow, it would also see a device and a session. Here it sees neither. The risk engine must decide using what remains.

Next, the engine checks the credential, which passes. It checks the signed scope, which matches the amount and the category. Then it asks about the operator behind the agent. If the agent is a known, long-standing assistant from a reputable platform, the engine approves. Furthermore, if the agent belongs to a fleet of near-identical agents that made forty small purchases of resalable goods across forty merchants today, the engine limits or declines.

The difference between the two outcomes is behavioral evidence about the agent and its operator. Credentials and signed scope were identical in both cases. The example shows why the third layer matters, and it shows how the layers work together.

A Practical Risk Policy for Agent Traffic

Risk teams can start with a short policy and refine it over time. The seven steps below work for issuers, acquirers, PSPs and merchants alike.

1. Classify the channel. Tag every transaction as human, agent-assisted or fully autonomous. Do this first, because every later metric depends on it.
2. Require a credential. Accept agent traffic only with a verifiable agent credential or token.
3. Check the mandate. Compare amount, merchant and time with the signed scope.
4. Score the operator. Use behavioral evidence about the agent’s owner, funding and fleet.
5. Set tier-based limits. Higher tiers earn higher limits and fewer step-ups.
6. Log for disputes. Keep the mandate, the credential, the score and the tier at decision time.
7. Review drift. Track agents whose behavior changes over time.

Start with limits, not blocks. Declining all agent traffic cedes a growing channel. Accepting all of it ignores the risk. A tiered policy sits between the two, and it improves as data accumulates.

A Tier-Based Treatment Table

The table below shows one way to map operator tiers to checkout treatment. Teams should adapt it to their own risk appetite.

Operator tier	Suggested checkout treatment
Sovereign	Standard limits, light monitoring
Trusted	Standard limits with periodic review
Provisional	Lower limits, step-up above a threshold
Elevated Risk	Small limits, user confirmation for most purchases
Untrusted	Decline

Aggregate by Operator

Limits per agent miss fleets. Aggregate velocity, spend and refund rates by operator and by shared funding source, so that one party cannot split a large purchase across many agents. Aggregation costs little and closes the most common loophole.

Metrics That Show Whether the Controls Work

A policy deserves measurement. Teams can track a short list of indicators and tune thresholds with data instead of guesswork.

• Approval rate by channel and tier. Higher tiers should show higher approval rates.
• Chargeback and dispute rate by channel and tier. Lower tiers should account for more losses. If they do not, thresholds need work.
• Step-up rate. Good customers should not face too many confirmations.
• Fleet detections. Count how many operators aggregate limits catch.
• Time to decision. Added latency can hurt conversion.
• Evidence completeness. Measure how many agent transactions carry a stored mandate, credential and score.
• Overrides. Every manual override needs a reason, and patterns point to policy gaps.

Leadership benefits from these numbers too. They turn a vague promise of agent safety into a visible control with measurable results.

What Fraud Teams Should Ask Their Vendors

Buyers can use a short list to test whether a product addresses agent risk or only relabels existing tools.

1. Which signals replace the human behavioral signals that agents remove?
2. Can the product tell an agent from a bot attack?
3. Does it detect fleets that spread small purchases across many agents?
4. How does it evidence its decisions for a dispute?
5. Does it re-evaluate agents over time, or only at onboarding?
6. What does it say it cannot cover?

Honest vendors answer the last question openly. A product that claims to cover everything has not described its limits. The same standard applies to ChainAware’s own score, which is why this article states plainly that the Agent Trust Score covers on-chain agents and wallets.

How Strong Authentication Fits an Agent Flow

Strong customer authentication exists to prove that the cardholder approved a payment. Tools such as 3-D Secure ask the cardholder to confirm through a challenge, and in return the liability for certain fraud shifts toward the issuer. The design assumes a person who can respond to a prompt on a phone or in a browser.

An autonomous agent cannot complete that challenge on its own. It has no fingerprint, no banking app and no one-time code. Teams therefore face a design question: where does the human approval happen, and how does the payment system learn about it? Two broad answers exist.

Approval before delegation. The user approves a scope up front, for example a monthly budget or a list of merchants. A signed mandate records that approval, and later payments reference it. This model fits routine purchases, such as subscription renewals.

Approval at purchase time. The agent pauses and asks the user to confirm a specific purchase. A confirmation may happen in a chat window or a banking app. This model fits large or unusual purchases.

How networks and issuers treat each model for liability purposes is still evolving. Risk teams should read their current network rules and ask their acquirers for guidance. Meanwhile, the practical advice is simple: store proof of whichever approval happened, and store it in a form that a third party can verify.

Where Behavioral Evidence Helps Authentication

Behavioral evidence about the operator does not replace the cardholder’s approval. It does help decide when to ask for one. A purchase from a long-standing, well-funded operator may need only the standing mandate. In addition, a purchase from an operator with a young wallet, an unknown funder and many sibling agents may deserve a live confirmation. Moreover, in this way, risk-based authentication extends naturally to agents.

Promotion and Refund Abuse at Machine Speed

Promotion abuse is one of the first places where agent fleets will pay off for attackers. A human can claim a sign-up bonus a few times before fatigue sets in. Furthermore, a fleet of agents can claim it thousands of times, each with a fresh identity and a plausible purchase.

Several features make the abuse attractive.

• Low unit risk. Each claim is small, so no single transaction triggers a review.
• Scripted patience. Agents can wait, rotate merchants and vary timing to avoid simple velocity rules.
• Cheap identities. Open registries make new agent identities nearly free, as the tracker data shows.
• Resale paths. Gift cards, digital goods and refundable items convert promotions into cash.

Refund abuse works in a similar way. A fleet buys, returns and repeats, and it captures a margin each time. Merchants that offer instant credit for returns face the highest exposure.

Controls That Work

Defenders can combine three controls.

1. Operator-level limits. Cap promotions, refunds and spend per operator and per funding source, not per agent.
2. Tier-based eligibility. Offer the best promotions to agents in higher trust tiers. Lower tiers receive standard offers or require human confirmation.
3. Delayed benefits. Release credits after a cooling-off period, so that fleet patterns appear before the merchant pays out.

The first control matters most. In the open registry, the weekly tracker shows farm shares between roughly 16% and 21% of agents in the weeks covered. If a payments ecosystem produces anything close to that mix, per-agent limits will fail, because the farm splits its activity across the many agents it controls.

Merchant Playbooks by Business Type

Agent risk differs by what a merchant sells. The right controls depend on delivery speed, resale value and dispute patterns.

Digital Goods and Software

Digital goods deliver instantly and resell easily. Fraud losses here come fast, and recovery is rare. Merchants should apply strict operator limits, delay high-value deliveries for lower tiers and watch for bulk purchases of keys, credits or gift cards.

Physical Goods

Physical goods give the merchant time. Shipping addresses, carrier data and delivery confirmation create extra evidence. Merchants should check the shipping address against the operator’s history and flag new addresses used by many agents.

Travel and Ticketing

Travel and ticketing involve high values and tight time windows. Agents will search and book at machine speed. Merchants should require stronger credentials and live confirmation for large bookings, and they should record the mandate that covers each trip.

Subscriptions

Subscriptions raise questions about recurring authority. An agent that renews a plan every month needs a mandate that says so. Merchants should tie each renewal to a standing mandate and alert the user when the price changes.

Marketplaces

Marketplaces face two-sided risk. Agents can act as buyers, sellers or both. A marketplace should score operators on each side and look for loops in which linked agents trade with one another to inflate reviews or volume.

When to Ask a Human to Confirm

A human in the loop adds friction, so teams should ask for confirmation only when risk justifies it. Likewise, a short rule set helps.

• Amount above a threshold. Set thresholds by tier, with lower limits for lower tiers.
• New merchant category. Ask when the agent leaves its usual pattern.
• New or changed mandate. Ask when the scope changes.
• Flag from the behavioral layer. Ask when the operator carries farm, funding or creator flags.
• Repeat after decline. Ask when an agent retries a declined purchase with different parameters.

Clear prompts matter. A confirmation message should state the merchant, the amount and the reason in plain language. Vague prompts train users to click through, and that habit erodes the control.

Two Illustrative Cases

The cases below are invented to show reasoning. They do not describe real incidents or real merchants.

Case One: The Quiet Fleet

A mid-sized online retailer opens agent checkout and sees steady growth. Chargebacks stay low. Yet margins on a popular promotion fall week after week.

An analyst groups orders by operator instead of by agent. Roughly sixty agents turn out to share one funding source. Each placed three to five small orders. None crossed a limit, and every mandate was valid. Seen together, they captured the promotion hundreds of times.

The retailer responds with operator-level limits and with tier-based eligibility for the promotion. Losses drop, and honest agents notice nothing. The lesson is that fleet abuse hides in aggregate data, and that per-agent controls never see it.

Case Two: The Drifting Assistant

A personal shopping agent starts well. It buys groceries and household items within a clear budget. After a model update, it begins to favor a single marketplace and to add accessories to each order. Every purchase fits the mandate. The user sees the monthly total and disputes several charges.

Meanwhile, the merchant has no fraud to show, but it does have logs. Baseline tracking would have flagged the change in merchant mix and basket size after the update. A re-authorization prompt would have let the user confirm the new behavior. Instead, the merchant absorbed the dispute costs.

The lesson is that drift belongs in the monitoring plan from the start. It also shows why dispute teams need access to logs, not just to payment records.

Data, Privacy and Governance

Behavioral evidence raises governance questions, and teams should address them early.

Data minimization. Collect the evidence that supports a decision and avoid storing more. Wallet addresses and agent identifiers are pseudonymous, but teams should still treat linked data with care.

Explainability. Decisions that decline or limit an agent need a clear reason. Tiers and named flags offer that reason in plain language. A black-box number without an explanation weakens both customer service and dispute defense.

Fairness. Honest new agents start with thin histories. A policy that treats every young agent as dangerous will punish newcomers. Offer a path to build trust, for example through lower limits that rise with a clean record.

Retention. Keep evidence long enough to cover dispute windows, and delete it when it no longer serves a purpose. Align retention with local law and with network rules.

Human review. Provide a way for operators to appeal a decision. Appeals catch model errors and build goodwill.

Build, Buy or Partner

Fraud teams must decide how to source behavioral evidence for agents. Each option has trade-offs.

Build. An in-house model fits your data and your risk appetite. It needs data engineers, labeled outcomes and time. Large issuers and networks often take this route, because they hold rich transaction data.

Buy. A vendor provides a ready score and an API. Integration is quick, and the vendor maintains the models. Teams should test accuracy on their own data and ask the six vendor questions listed earlier.

Partner. A hybrid model combines a vendor’s on-chain evidence with the team’s own card data. This route suits payments companies that handle both stablecoin and card flows.

For on-chain agents and wallets, the buy route is often fastest. The Agent Trust Score offers a free tier for experimentation, and the Prediction MCP lets agents call the checks directly. Teams that screen wallets for DeFi or token risk can also review the comparison of DeFi compliance tools and the guide to blockchain data providers for AI agents.

Common Mistakes to Avoid

Teams that start early tend to repeat a small set of errors. Avoiding them saves months.

1. Treating credentials as trust. A valid credential proves registration, not good intent.
2. Scoring agents one by one. Fleets hide inside operator-level patterns.
3. Checking once at onboarding. Profiles change, so scores need refresh cycles.
4. Skipping evidence storage. Without stored mandates and scores, disputes turn into guesswork.
5. Blocking all agents. A blanket ban pushes good traffic to competitors.
6. Approving all agents. Open acceptance invites the fleets that cheap identities make possible.
7. Ignoring the human prompt. Vague confirmation prompts train users to click through.
8. Waiting for final rules. Liability rules will take time, and agent traffic is already here.

A Quick Self-Assessment

Teams can test their readiness with five questions.

• Can we tell agent traffic from human traffic in our logs?
• Does authorization verify a credential and a mandate?
• Is the operator, its funding and its fleet scored?
• Our team stores evidence for every agent decision, correct?
• Drift reviews and scheduled re-scoring happen, right?

A team that answers yes to all five has a strong foundation. By contrast, a team that answers no to three or more should start with the 90-day plan below.

Building the Dispute Evidence Package

Disputes will decide who bears the loss in practice, whatever the rules say on paper. Teams that prepare evidence in advance resolve disputes faster and win more of them. An evidence package for an agent transaction should contain six items.

1. Credential or token. Proof that a registered agent made the request.
2. Signed mandate. A record of what the user asked for and approved, including amount, scope and time.
3. Decision log. Inputs and the rule that produced the approval or the step-up.
4. Behavioral score. Operator tier and flags at decision time.
5. Fulfilment record. Proof of delivery or service, as in any card dispute.
6. User confirmation, if any. Any step-up or confirmation that the user completed.

Why Timing Matters

The score and the flags must reflect the moment of the decision. A score from today does not explain an approval from last month. Store the lookup result with the transaction, including the time. When a dispute arrives weeks later, the stored record shows what the team knew when it acted.

Who Collects What

The merchant usually holds the order and fulfilment data. Likewise, the PSP or acquirer often holds the token and authorization data. The agent operator holds the instruction log. A good dispute process lets each party share its part, and standards bodies can help by defining formats. Until then, merchants can ask operators to provide logs on request as part of their agent policy.

Agent Drift and Continuous Monitoring

Agent drift deserves a closer look, because it creates disputes without clear fraud. An agent may start as a faithful assistant and drift as its model, tools or instructions change. Each purchase stays within the signed mandate, yet the pattern no longer reflects what the user wanted.

Three practices help.

Baseline behavior. Record each agent’s normal spend, merchant mix and timing. A baseline makes change visible.

Flag shifts. When an agent’s behavior moves far from its baseline, trigger a review or ask the user to reauthorize.

Re-score the operator. A change in the operator’s funding, ownership or fleet structure can signal that the agent now serves a different purpose. Scheduled re-checks catch these changes.

Behavioral trust layers support the third practice directly. A score that refreshes on a schedule shows when an operator’s profile changed. The weekly Agent Trust Tracker shows how fast profiles move in a live registry, with the median trust of new agents ranging from 918 in Week 36 to 101 in Week 41. If profiles move that fast, a one-time approval cannot carry a long relationship.

Wallets, Stablecoins and the On-Chain Preview

Card rails are only one route for agent payments. Stablecoins and wallet-based settlement are growing too, and agents suit them well. They can hold funds, sign transactions and pay in seconds. The x402 approach, described in the liability analysis, lets agents pay over HTTP with on-chain settlement.

On-chain settlement brings a different mix of risks and tools. Funds move without chargebacks, so prevention matters more than dispute. At the same time, the ledger is public, so evidence about the payer is open. Behavioral scoring of wallets, feeders and fleets works well in this setting. ChainAware’s fraud detection API screens wallets at scale, and the guide to Web3 fraud detection for DApps explains why wallet screening beats transaction simulation alone.

The on-chain world also previews the future of card-based agent commerce. Its registry shows what open registration produces: cheap identities, fleets and opaque funding. Payments teams can learn from that data without waiting for their own ecosystems to mature. The overview of the Web3 agentic economy explains why machine-readable trust becomes core infrastructure.

Regulated Teams and Compliance

Regulated teams face additional duties. Anti-money-laundering and sanctions rules apply to payments regardless of who initiates them. When an agent pays, the institution still needs to know whom it deals with. A deeper review tool such as ChainAware Investigation turns a wallet address into a structured seven-section report in about a minute, and the overview of autonomous compliance screening shows how agents and screening fit together. For protocols with regulatory duties, the DeFi compliance guide explains which obligations apply.

A 90-Day Plan for Payments Teams

Teams that want to act can follow a simple plan.

Days 1 to 30: Measure

Tag agent traffic in your logs and reports. Count how many transactions come from agents, and which merchants and operators generate them. Record chargeback rates by channel. Do not change policy yet, because the baseline guides every later decision.

Days 31 to 60: Design

Choose the credential and mandate formats that you will require for agent traffic. Pilot a behavioral score on a sample of agents and compare outcomes by tier. Write a one-page limits policy by tier, with owners and a review date.

Days 61 to 90: Enforce

Turn the policy on for new agent traffic. Aggregate limits by operator, store evidence for every agent transaction and review overrides weekly. Report the metrics to leadership, including the dispute rate by tier.

By day 90, the team has a documented control, a measurable baseline and a clear owner. That outcome serves better than waiting for final industry rules, because the rules will take time and the traffic is arriving now.

Where Agent Payments Fraud Is Heading

Four trends will shape the next two years.

Standards Will Converge Slowly

Protocols will multiply, and standards bodies will work to align them. Merchants will face a mix of credential formats for some time. A thin internal layer that normalizes identity and mandate data will help teams adapt.

Liability Rules Will Firm Up

Networks and regulators will clarify who bears the loss for agent-initiated transactions. Until then, teams should plan for the merchant of record to carry much of the risk, and they should gather the evidence that supports a defense.

Fleets Will Get Bigger and Subtler

Operators will learn to spread purchases across more agents, more merchants and more funding sources. Detection will need to look at operator-level patterns and shared funding, not just individual transactions. The experience of the open registry, where farms stayed between roughly 16% and 21% of agents across weeks, suggests that fleets persist even when defenders push back.

Behavioral Evidence Will Become a Standard Layer

Credentials and mandates will prove permission, and behavioral evidence will estimate risk. Payments teams will treat the three layers as a standard stack, much as they treat tokens, 3-D Secure and risk scoring today.

Why ChainAware Fits the Behavioral Layer

Payments teams need a behavioral layer that predicts loss and resists gaming. Review-based rankings fail that test, because 50 fake agents can upvote a 51st. The Agent Trust Score uses on-chain behavior only, and the attacker’s own address and feeder pass through machine-learning fraud detection. ChainAware reports 95% accuracy for its per-address fraud model, which anyone can verify through ScamDB, and its rug pull model predicted 90.1% of cases before they happened in a PancakeSwap test on the rug pull verification page. The score estimates risk from the owner, the funder, the creator and the fleet, and it does not rank agents.

Key Facts at a Glance

• The four-party card model assumes that someone can observe and verify a human at checkout.
• AI agents remove device, session and behavioral signals, so fraud models lose much of their input.
• Agents act as a fifth participant, and liability for agent-initiated transactions is still being settled.
• Credentials and signed mandates prove permission. Behavioral evidence about the operator estimates risk.
• Six new scenarios stand out: impersonation, mandate abuse, drift, fleet abuse, agent alibi disputes and compromised agents.
• ChainAware’s Agent Trust Score rates ERC-8004 agents from 0 to 1,000 across five tiers, using the owner wallet, the feeder, the creator’s record and fleet detection.
• At launch, 51.8% of 274,792 indexed agents sat in the two lowest tiers, and 21.1% carried the farm flag.
• The score covers on-chain agents and wallets, and card-only ecosystems need their own behavioral data.

Frequently Asked Questions

What is the four-party model in card payments?

It consists of the cardholder, the merchant, the issuer and the acquirer, with a card network connecting issuer and acquirer.

Who is liable when an AI agent makes a fraudulent purchase?

Rules are still developing. Some analysts expect the merchant of record to carry the loss by default. Check your network and acquirer rules, and gather evidence for disputes.

Why do traditional fraud models struggle with agents?

They depend on human behavioral signals such as device and typing patterns. A server-side agent produces none of them.

What is the Agentic Commerce Protocol?

It is a protocol launched by OpenAI and Stripe that lets agents pay using a shared payment token instead of raw card details.

What is AP2?

AP2 is Google’s Agent Payments Protocol. It uses verifiable credentials and signed mandates to record what users asked for and approved.

What is agent drift?

Agent drift is a gradual change in an agent’s behavior that leaves it technically authorized but no longer aligned with the user’s intent.

How does fleet abuse work?

An operator runs many agents that look independent and makes small purchases that exploit promotions or refund policies. Aggregating limits by operator and by funding source catches it.

Does the Agent Trust Score work for card payments?

The score covers on-chain ERC-8004 agents and their wallets. It does not cover agents that never touch a public chain, though the approach carries over to other ecosystems.

Is the Agent Trust Score free?

The score is free for public indexed agents, with 1,000 queries per month and no signup. Teams with higher volume can use the API or the Prediction MCP. See the Agent Trust Score page for current details.

What should a payments team do first?

Tag agent traffic, measure it and set tier-based limits. Then add mandate checks, operator-level aggregation and evidence storage.

A Short Glossary of Agentic Commerce Terms

• Agentic commerce: commerce in which software agents choose and complete purchases on behalf of users.
• Issuer: the cardholder’s bank, which approves or declines each transaction.
• Acquirer: the merchant’s bank or processor, which accepts card transactions and settles funds.
• Merchant of record: the party that sells to the customer and appears on the cardholder’s statement.
• Mandate: a signed record of what a user authorized an agent to do.
• Shared payment token: a limited-use credential that lets an agent pay without exposing card details.
• Agent drift: a gradual change in agent behavior away from the user’s intent.
• Fleet: a group of agents that share an operator, funding source or both.
• Know Your Agent (KYA): the process of deciding whether an agent may act and how far.
• Agent Trust Score: ChainAware’s 0 to 1,000 rating for ERC-8004 agents, with five tiers and named flags.

Conclusion: Add the Third Layer

The four-party model worked because someone could verify a human. Agents break that assumption, and the industry is rebuilding the pieces. Tokens keep card details safe. Credentials identify agents. Mandates record permission. These layers matter, and they do not finish the job.

The missing layer measures risk. It asks how the agent’s operator behaves, where its money comes from and how many siblings it has. That evidence replaces some of the signals that agents remove, and it helps issuers, acquirers, merchants and operators make proportionate decisions.

Start small. Tag agent traffic, set tier-based limits, store evidence for every decision and review the results monthly. For the wider picture, read our companion guide on verifying AI agents at checkout, the pillar article on Know Your Agent and the analysis of ERC-8004 trust signals. The agent trust infrastructure race compares how providers approach the problem, and the guide to Web3 Sybil protection systems covers fleet detection in depth. In addition, ChainAware’s 32 Claude sub-agents show how an agent fleet can apply these checks in practice.

Reading the Tracker as an Early Warning System

Payments teams rarely get a public dataset that shows how an open agent ecosystem behaves. The weekly ERC-8004 tracker offers one. It does not predict card fraud, yet it reveals dynamics that any open registration system tends to show. Four observations stand out.

Volume swings fast. Weekly registrations hit a record of 31,979 in Week 34 and fell to 10,706 by Week 41. A risk team that sizes controls for the average week will struggle in the peak week.

Quality swings with volume. The median trust of new agents reached a record 918 in Week 36 and dropped to 101 in Week 41. In other words, a quiet stretch of good agents can end abruptly when a new wave arrives.

Farms persist. The farm-detected share of agents stayed in a range of about 17% to 19% across Weeks 32 to 34. Defenders do not eliminate fleets by naming them once.

Technology shifts. The count of agents delegated through EIP-7702 grew about 33.8% between Week 35 and Week 40. New account mechanics change what signals exist and how attackers hide them.

What This Means for Card-Based Agent Programs

Payments teams can read these patterns as a warning. If cheap identities, rapid waves and persistent fleets appear in an open registry, similar dynamics can appear wherever agent onboarding is easy. Controls should therefore scale with traffic, refresh often and look at operators rather than single agents.

The companion article on agent fraud patterns from the tracker walks through these weeks in detail. For one view of how fast the picture can change, compare the Week 36 tracker with the Week 40 tracker.

Questions Boards and Regulators Will Ask

Senior leaders and supervisors will soon ask about agent risk. A prepared team can answer five questions with evidence.

1. How much of our volume comes from agents? Channel tagging gives the number.
2. What are our losses by channel? Dispute data by channel and tier gives the answer.
3. Who carries liability in each flow? A one-page map of contracts and network rules gives the answer.
4. How do we know an agent is permitted to act? Credential and mandate checks give the answer.
5. How do we manage risky operators? Tier-based limits and re-scoring give the answer.

Written answers, kept current, turn a vague risk into a managed one. They also speed up audits and partner reviews, because the evidence already exists.

What Good Looks Like in Twelve Months

A mature agent payments program looks calm from the outside. Behind the scenes, it has a few clear features.

• Every transaction carries a channel tag, and agent traffic has its own dashboard.
• Credentials and mandates are checked at authorization, and the results are stored.
• Operator-level scores guide limits, step-ups and promotion eligibility.
• Scores refresh on a schedule, and drift alerts reach an owner.
• Dispute packages assemble automatically from stored evidence.
• Quarterly reviews adjust thresholds based on loss data and approval rates.

Teams that reach this state can welcome agent traffic with confidence. Competitors that stay undecided will either lose the channel or lose money in it.

Frequently Overlooked Details for Implementation Teams

Engineering and operations teams often hit the same small snags. A short checklist saves rework.

Time synchronization. Store timestamps for mandates, credentials, scores and decisions in one standard format. Disputes hinge on sequence, and clock drift muddies it.

Idempotency. Agents retry. A payment service that treats a retry as a new purchase will double charge. Use idempotency keys and log every retry.

Identifier mapping. Agent identifiers, wallet addresses, merchant accounts and card tokens live in different systems. Build a mapping table early, and keep it versioned.

Fallback behavior. Decide in advance what happens when a score lookup fails. A safe default is a lower limit and a step-up, not a full approval or a full block.

Cache lifetimes. Cache scores for a short, defined time, and tie the lifetime to the tier. Low tiers deserve fresher data.

Monitoring the monitor. Track lookup latency, error rates and coverage. A control that silently stops working is worse than no control, because the team trusts it.

Who Owns What

Agent risk crosses teams. Fraud owns the models and limits. Payments engineering owns the authorization path. Legal and compliance own liability maps and regulatory duties. Product owns the user prompts. A named lead for agent traffic keeps these pieces aligned, and a monthly review keeps the plan current.