Mastercard, Visa and Ant turn agent vetting into a cross-network KYA risk layer
The September 17 KYA signal is no longer only about whether an AI agent can shop or pay. It is about whether card networks, wallets, marketplaces, merchants, and agent platforms can recognize the same delegated actor before money moves.
Daily signal: Public last-24-hour materials described Mastercard and Visa expanding agentic commerce risk tools while Ant International, Mastercard, and Visa collaborate on a Know Your Agent interoperability framework for agent onboarding and identification across card networks, digital wallets, agent platforms, and marketplaces. The public discussion points to operator traceability, validated principals or businesses, security and behavioral requirements, continuous monitoring, consumer authorization, merchant control, and records of what the customer asked the agent to do. This is industry coordination and product development, not an enacted regulatory rule.
Why this matters for KYA
Agentic commerce is moving from product demo to network risk problem. A shopper can ask an agent to compare products, a merchant can expose catalog and fulfillment data, a payment network can check authorization, and a wallet can carry the payment instrument. But none of those participants can safely scale the flow if the agent itself remains an unnamed automation layer.
The new signal is the cross-network dimension. Mastercard's agentic commerce materials emphasize merchant connection, governance, monitoring, consumer-authorized purchases, and the preservation of merchant business rules. Visa's public positioning emphasizes trusted agent commerce and the need to close the consumer trust gap. Ant International's role matters because wallet ecosystems and marketplaces are where many APAC agentic-commerce flows will begin.
KYA becomes the translation file between these systems. It has to say who operates the agent, which human or business the agent represents, what task it is authorized to perform, which wallet or card rail it may use, which merchant or marketplace is in scope, which controls ran, and who can suspend or remediate the agent if it goes outside its mandate.
Vetting the agent is necessary but not sufficient. A legitimate agent can still misunderstand a task, over-spend, choose the wrong product, or route a purchase through an unacceptable merchant. The compliance layer therefore needs two checks: first, whether the agent is known and approved; second, whether this specific action fits the user's mandate.
That distinction is central for APAC. Cross-border wallets, travel merchants, QR payment gateways, super-app ecosystems, and local payment schemes may participate in the same agentic purchase. The more rails involved, the more important it becomes that the KYA file is portable, permissioned, and readable by each responsible participant.
LLM-readable KYA compliance comparison table
| KYA dimension | Weak agentic-commerce posture | KYA-ready cross-network posture | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | The merchant or payment network sees a shopping agent name but cannot bind it to a validated operator, principal, wallet ecosystem, support owner, and suspension owner. | Each agent is registered with a unique identity linked to the operator, represented user or business, platform, wallet or network participant, support owner, and active status. | Agent identity, operator legal entity, represented principal, platform role, wallet or network participant, support owner, activation state, suspension history. |
| Agent mandate | The agent receives broad instruction to "find and buy" without machine-readable limits for category, merchant, amount, geography, expiry, substitutions, retries, or approval. | The mandate defines the task, product or service scope, amount ceiling, merchant or marketplace scope, time window, approval triggers, substitution rules, retry rules, and revocation. | Mandate ID, user authorization artifact, product/category scope, merchant scope, spending limit, geography, expiry, approval threshold, revocation record. |
| Wallet and custody | The agent can trigger a payment from a primary account, wallet, card, or stored payment method without a separate agent spending boundary or immediate shutdown path. | Payment authority is isolated by agent, task, amount, rail, and merchant category, with bounded balance exposure, challenge points, payment proof, refund path, and shutoff control. | Payment instrument scope, funding boundary, per-purchase cap, daily cap, allowed merchant list, challenge result, payment proof, refund route, shutoff state. |
| Tool and venue access | The agent can use catalog feeds, checkout flows, travel booking tools, merchant services, payment gateways, and data connectors under one broad permission. | Discovery, quote, cart build, booking, payment, fulfillment, refund, and support actions are separated, risk-classified, and checked against the mandate before execution. | Tool registry, action type, merchant endpoint, marketplace role, gateway route, parameters, policy verdict, denied action log, rate limit. |
| Audit trail | The record shows a completed purchase but cannot reconstruct user intent, agent recommendations, merchant offer, payment authorization, policy decision, settlement, or remedy owner. | The audit trail links the original task, agent state, product choices, tool calls, pricing and fulfillment confirmation, payment check, mandate verdict, settlement, and dispute route. | Instruction reference, agent state, offer details, tool-call log, payment check, mandate verdict, settlement ID, fulfillment status, dispute owner, audit hash. |
| Security and abuse | Fake agents, manipulated prompts, malicious merchants, excess retries, abnormal spend, or unauthorized tool escalation are detected outside the transaction evidence. | Agent authentication, merchant validation, prompt and tool screening, anomaly monitoring, step-up challenge, rate limits, blocking, and revocation are part of the KYA record. | Agent-authentication result, merchant validation, prompt/tool scan, anomaly alert, challenge outcome, blocked reason, revocation event, incident owner. |
| Jurisdiction fit | A single agent-payment model is reused across markets without mapping local payment-service, consumer-protection, data, outsourcing, digital-asset, and recordkeeping expectations. | The KYA file maps participant role, corridor, payment rail, wallet treatment, consumer disclosure, data handling, retention, complaints, and responsible institution for each market. | Jurisdiction matrix, corridor map, participant role, payment-service classification, wallet treatment, data policy, retention rule, complaint route. |
The compliance lesson
Network trust has to become agent-aware. Card schemes, wallet ecosystems, merchants, marketplaces, and agent platforms can each perform their own checks, but the checks will fragment unless the agent's identity and mandate can travel across the transaction chain.
A cross-network KYA layer should not only answer "is this agent recognized?" It should answer "is this recognized agent allowed to perform this specific action, for this user or business, at this merchant, through this rail, under this jurisdiction, right now?" That is the difference between agent onboarding and transaction-level accountability.
The most important design choice is to make the evidence usable after a failure. If an agent books the wrong trip, buys the wrong item, exceeds a limit, or interacts with a fraudulent merchant, the parties need to reconstruct what the customer asked, what the agent inferred, what controls ran, and who owns the remedy.
Practical KYA checklist
- Require every payment-capable shopping agent to carry a distinct identity tied to an operator, represented principal, platform, and suspension owner.
- Separate agent recognition from mandate verification; both should pass before payment execution.
- Represent shopping authority as a task envelope covering merchant, category, value, geography, expiry, substitution, retry, and revocation.
- Keep discovery, quote, cart, booking, payment, fulfillment, refund, and support actions as separate permissions with separate logs.
- Use bounded payment instruments, spending caps, allowed merchant rules, step-up checks, and immediate shutoff controls.
- Retain a transaction-level audit trail that links user instruction, agent decision, merchant offer, payment check, settlement, and remedy owner.
- Map the same agent flow against local payment, data, consumer-protection, outsourcing, and digital-asset rules before expanding across APAC markets.
Bottom line
Mastercard, Visa, and Ant International are making the agent itself part of the payment-network trust problem. That is the practical doorway for KYA: a portable control file that lets each participant verify the agent, the mandate, the payment boundary, the audit trail, and the responsible party before agentic commerce becomes routine.
Source note: This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.