Agentic Rails Atlasby merces.ai

Persona

Card issuer risk and product lead

Authorization decisions, fraud, disputes, Regulation E exposure.

Verified (verified under 30 days ago)

Role

Goals

  • Approve legitimate agent purchases at the same rate as cardholder-present purchases.
  • See in the authorization message that an agent initiated the transaction, and which agent.
  • Bind each agentic token to a cardholder consent event and a set of limits the issuer can enforce.
  • Keep Regulation E and Regulation Z losses within model, even when the cardholder shared credentials with an agent.
  • Give cardholders a way to see and revoke agent permissions from the banking app.
  • Join network programs (Agentic Ready, Agent Pay enablement) without re-engineering the authorization host.

Pains

  • Agent indicators arrive inconsistently, so the network is testing a probability score instead of a flag.
  • Under 12 CFR 1005.2(m), a transfer by an agent the consumer furnished credentials to is not unauthorized until notice, so the issuer and the cardholder argue over who takes the loss.
  • No agent-specific dispute reason codes or liability shift exist, so an agent error is a regular dispute with weak evidence.
  • Open mandates and autonomous intent credentials can run for weeks, and the issuer has no hook to pause them.
  • Step-up authentication is left to the networks in AP2 v0.2, and each network's passkey and token scheme differs.
  • Visa's and Mastercard's agentic tokens are different products with different data fields.

Decisions they own

  • Whether to enroll in network agent programs and which controls to require on agentic tokens.
  • Authorization strategy for agent-initiated transactions: approve, step up, or decline by segment.
  • How to treat disputes on agent purchases under Regulation E and Regulation Z.
  • What cardholder-facing controls to ship: per-agent limits, merchant lists, revoke.

Vocabulary

  • authorization
  • decline
  • chargeback
  • Regulation E
  • Regulation Z
  • agentic token
  • MDES
  • step-up
  • passkey
  • reason code
  • liability
  • cardholder
  • probability score
  • consent

Each protocol from this seat

Relevance levels: High, a main persona on the protocol page; Medium, owns, implements or verifies a step; Low, relies on or observes a step; None, no role found in the protocol page.

ERC-8004: Trustless Agents

Relevance: None

Not one of the main personas on the ERC-8004: Trustless Agents page. The responsibility table gives this persona no step.

x402

Relevance: None

Not one of the main personas on the x402 page. The responsibility table gives this persona no step.

Visa Trusted Agent Protocol

Relevance: High

Issues the Visa cards that VIC tokenizes for agents and decides on authorization, without seeing the TAP signature itself. Source [1, 2, 3, 4]

Goals

  • Approve legitimate agent purchases
  • Keep step-up and passkey checks effective
  • Know which transactions an agent started

Pains

  • No public agent transaction indicator from Visa
  • No agent-specific liability rule
  • Customers who dispute what their agent bought

Implements

  • Step-up verification and passkey setup for agent tokens through VIC
  • Risk rules for agent-specific tokens
  • Agentic Ready participation

Must trust

  • Visa's onboarding of agents
  • Merchants and CDNs to verify TAP
  • VIC confirmations as evidence in disputes

Questions they ask

  • Can I tell a TAP-verified purchase in the authorization message?
  • Who carries the loss when an agent misreads the user?
  • What does the passkey approval prove in a dispute?

First three steps

  1. Join Visa's Agentic Ready program
  2. Review how VIC step-up and passkeys work for my cardholders
  3. Map agent token transactions in fraud monitoring

Metrics they care about

  • Approval rate on agent tokens
  • Fraud and dispute rate on agent purchases
  • Passkey enrollment rate

A day in the life. Lena runs digital fraud at a European bank in the Agentic Ready program. Her cardholders now link cards to shopping agents: VIC runs step-up verification, the user sets up a passkey, and the agent gets its own token. When a purchase arrives she sees a token transaction, not the merchant's TAP check, so she relies on Visa's signals. A customer disputes a hotel booking made by an agent. The passkey approval of the Payment Instruction helps, but no agent-specific liability rule exists yet, so the case runs under the usual card rules.

Steps in the responsibility table

  • Relies onOnboard the agent and register its key
  • Relies onApprove the purchase instruction with a passkey (VIC)
  • OwnsAuthorize the card payment
  • OwnsHandle a dispute on an agent purchase

Agentic Commerce Protocol (ACP)

Relevance: None

Not one of the main personas on the Agentic Commerce Protocol (ACP) page. The responsibility table gives this persona no step.

UCP

Relevance: None

Not one of the main personas on the UCP page. The responsibility table gives this persona no step.

AP2

Relevance: High

Card issuer or bank: may receive the Payment Mandate through the network or act as Credential Provider, and uses mandates as dispute evidence. Source [5, 6, 7]

Goals

  • Know an agent purchase was user-approved
  • Fewer first-party disputes
  • Clear liability

Pains

  • Liability stays with network rules that are not yet agent specific
  • No step-up mechanism in v0.2
  • Production evidence missing

Implements

  • Mandate verification where it acts as Credential Provider or behind the network
  • Dispute verification of mandates and receipts
  • Risk decisions using risk_data

Must trust

  • The network to pass mandates intact
  • The Trusted Surface to have authenticated the user
  • Receipts to be signed by the right parties

Questions they ask

  • Does a mandate change chargeback rights?
  • How do I challenge the user if v0.2 has no step-up?
  • Who retains mandates for disputes?

First three steps

  1. Read the Dispute Evidence and Verification: Dispute sections
  2. Check how your network plans to carry mandates
  3. Decide how unresolved_constraint fallbacks reach your authentication flow

Metrics they care about

  • Disputes with mandate evidence attached
  • Approval rate on mandate-backed transactions
  • Fallback rate to manual approval

A day in the life. Helen handles disputes at a regional bank. A customer says her agent bought the wrong concert tickets. The merchant supplies the Checkout Mandate and receipt, and the network passes the Payment Mandate. Helen's tool recomputes the hash of the checkout JWT, matches both receipt references and confirms that the agent's closed mandate sits inside the customer's open one, with the venue and price allowed. The evidence shows the agent stayed inside its limits, so the dispute turns on whether those limits matched what the customer meant. AP2 cannot answer that, and the network rules say nothing specific about agents yet. She escalates it.

Steps in the responsibility table

  • VerifiesVerify the Payment Mandate and issue a token
  • OwnsVerify mandates and receipts in a dispute
  • ImplementsSet retention and consent policy

Mastercard Agent Pay

Relevance: High

Issues the card behind the agentic token, is enabled for Agent Pay at network level, and makes the final authorization decision. Source [8, 9, 10, 11, 12]

Goals

  • Approve good agent purchases without extra friction
  • See clearly when an agent was involved
  • Keep fraud and dispute rates flat as agent traffic grows

Pains

  • No published agent-specific reason codes or liability shift
  • Agent flags that are not always present, hence the 2026-09-30 probability score test
  • Verifiable Intent evidence that is not yet documented inside live authorizations

Implements

  • Network-level enablement for Agent Pay
  • Passkey authentication for consumer consent where offered
  • Authorization rules that read the additional information in the message

Must trust

  • Mastercard to register and certify agents
  • The network to detokenize and enforce token limits
  • The agent platform to capture the consumer intent accurately

Questions they ask

  • Which data element tells me an agent initiated this transaction?
  • Who carries the loss when an agent buys the wrong thing within its limits?
  • Can I read a Verifiable Intent chain today, or only later?

First three steps

  1. Confirm with Mastercard that your BINs are enabled for Agent Pay
  2. Map how agent transactions appear in your authorization and dispute systems
  3. Read the Verifiable Intent security model and its dispute evidence section

Metrics they care about

  • Agent transaction approval rate
  • Fraud and dispute rate on agent transactions
  • Share of agent transactions that carry reliable agent information

A day in the life. Priya runs card authorization strategy at a mid-sized European bank. On 2026-06-02 Mastercard said all its European issuers were enabled for Agent Pay at network level, so agent transactions may already reach her systems. She wants to approve them without new friction, but her dispute team asks a hard question: when a cardholder says the agent bought the wrong hotel, which reason code applies? Nothing agent-specific is published. She asks Mastercard which message field marks agent involvement, sets a rule to review those transactions separately for a quarter, and reads the Verifiable Intent dispute evidence section to see what proof she could ask for later.

Steps in the responsibility table

  • Relies onAuthenticate consumer and set limits
  • Relies onProvision agentic token
  • Relies onDetokenize and check token limits
  • Relies onVerify Verifiable Intent chain
  • OwnsApprove or decline
  • OwnsHandle dispute

Sources

  1. Visa Intelligent Commerce overview (Visa Developer Center) (external link)Visa. Documentation, primary source. Accessed .
  2. Visa launches Agentic Ready programme to advance agentic commerce in Europe (external link)Visa. Announcement, primary source. Published . Accessed .
  3. Visa and Banks Across Europe Reach the Next Phase of Agentic Commerce, Unlocking Secure Access to Merchants (external link)Visa. Announcement, primary source. Published . Accessed .
  4. Agentic commerce liability is still being written (external link)Worldpay. Analysis. Published . Accessed .
  5. Agentic Payment Protocol (v0.2) specification (external link)Google (google-agentic-commerce). Specification, primary source. Published . Accessed .
  6. AP2 FAQ (external link)Google (google-agentic-commerce). Documentation, primary source. Published . Accessed .
  7. Agentic commerce liability is still being written (external link)Worldpay. Analysis. Accessed .
  8. Europe is Building the Foundations for Trusted Agentic Commerce (external link)Mastercard Newsroom (Brice van de Walle). Announcement, primary source. Published . Accessed .
  9. Level 1 Agentic Commerce: Enable Agent Support with Minimal Changes (external link)Mastercard Developers (Merchant Cloud tutorials). Documentation, primary source. Accessed .
  10. Mastercard Advances Agentic Commerce With New Trust and Intelligence Services (external link)Mastercard (Investor Relations, Business Wire release). Announcement, primary source. Published . Accessed .
  11. Verifiable Intent: Security Model and Threat Analysis, version 0.1-draft (external link)agent-intent (Verifiable Intent Working Group). Specification, primary source. Published . Accessed .
  12. Mastercard Agent Pay review (external link)Nevermined. Analysis. Published . Accessed .

Source details

    Loading the index.

    Enter open Esc close ? shortcuts