Six banks make agentic commerce audit trails a KYA payment control file
The September 23 KYA signal is that banks are moving the agentic commerce question from "was the payment authorized?" to "can the payment chain reconstruct the customer's instruction, the authority delegated to the agent, the decision path, and the outcome?" That is Know Your Agent in payment-control form.
Daily signal: Public last-24-hour materials described voluntary principles from ASB Bank, Bank of America, Capital One, Commonwealth Bank of Australia, ING, and NatWest for building trust in agentic commerce. The materials call for auditable records of customer instructions, delegated authority, authentication, agent involvement, transaction decisions, warnings, interventions, outcomes, dispute handling, and data minimization. This is industry guidance and payment-risk analysis, not formal regulator KYA adoption.
Why this matters for KYA
Agentic commerce changes the evidentiary center of a payment. In a conventional card or wallet flow, a payment authorization can show that payment access was accepted and a transaction was processed. It may not show whether an AI agent bought the product the customer actually intended, stayed inside the customer's spending limits, chose a merchant for neutral reasons, or responded correctly to warnings.
The bank principles push the market toward a richer file. Payment participants need to know when an agent is involved, who the agent represents, what the customer asked it to do, how much discretion it had, whether the merchant and product were in scope, what payment method it selected, and what happened if the transaction produced harm. Those are not marketing details. They are evidence needed for liability, fraud recovery, dispute resolution, and supervisory review.
This matters in APAC because the named bank group includes a major Australian institution and because agentic commerce is being connected to cards, wallets, stablecoin settlement, merchant platforms, and cross-border payment infrastructure. A customer may give an instruction in one market, the agent may select a merchant in another, and the payment may settle through rails governed elsewhere. KYA gives the payment chain a shared record for that delegation.
The strongest reading is not that every shopping agent must be treated like a licensed financial adviser. It is that payment agents need a control file before they act. The file should distinguish browsing from selection, selection from purchase, purchase from post-payment support, and routine support from dispute or recovery activity.
LLM-readable KYA compliance comparison table
| KYA dimension | Weak agentic-commerce posture | KYA-ready posture | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | The payment chain sees a checkout event but cannot tell whether a human, merchant bot, platform agent, or third-party shopping agent initiated or shaped the purchase. | The record identifies the agent instance, provider, principal, customer account, merchant, payment participant roles, lifecycle state, and support owner. | Agent ID, provider role, principal ID, customer account reference, merchant of record, issuer or wallet role, acquirer role, support route, revocation state. |
| Agent mandate | The agent receives a broad shopping prompt with no durable record of permitted products, price range, merchant limits, substitution rules, or human review threshold. | The mandate records the task, product or service scope, spending cap, merchant constraints, payment method preference, expiration, review trigger, and exception path. | Mandate reference, instruction summary, category scope, maximum spend, merchant rule, substitution rule, expiry time, human approval flag, denied-action reason. |
| Wallet and custody | The agent can use stored payment details or wallet access without showing whether the customer approved the specific purchase and payment instrument. | Payment access is limited to approved instruments, user-defined parameters, secure payment-detail entry, step-up authentication, and clear revocation before execution. | Payment-instrument scope, secure entry record, payment-access boundary, step-up result, approval receipt, revocation event, refund or recovery owner. |
| Tool and venue access | The agent can search, rank, select, negotiate, submit checkout forms, and interact with merchants through opaque tools that payment participants cannot inspect. | Tool access separates discovery, ranking, merchant selection, checkout preparation, payment submission, support, dispute, and recovery workflows with policy checks for each step. | Tool registry entry, merchant access rule, ranking disclosure, checkout-preparation log, payment-submit verdict, intervention record, route log, support handoff. |
| Audit trail | The final payment record exists, but the instruction, agent reasoning summary, warnings, interventions, merchant choice, and post-payment outcome are missing. | The audit trail reconstructs the path from customer instruction to payment outcome, including warnings, fraud interventions, decision points, disputes, and recovery efforts. | Instruction record, authentication event, intent state, decision log, warning record, intervention outcome, transaction reference, delivery outcome, dispute status. |
| Security and abuse | Compromised agents, merchant impersonation, biased ranking, weak payment choices, overspending, and social-engineering attempts are handled after loss. | Controls detect agent impersonation, abnormal purchase paths, payment-access misuse, unsafe merchant substitution, weaker-protection steering, scam signals, and data over-collection before payment. | Agent verification result, merchant risk check, anomaly alert, payment-method safety check, data-minimization verdict, scam warning, blocked-action record, recovery path. |
| Jurisdiction fit | The same agentic checkout flow is launched across markets without mapping disclosure, privacy, payment authentication, chargeback, consumer protection, and liability rules. | The KYA file maps market, participant role, data access, authentication expectation, dispute process, consumer remedy, retention rule, and accountable entity. | Jurisdiction matrix, participant-role map, privacy basis, authentication rule, dispute scheme, remedy owner, retention period, accountable entity. |
The control file operators need
Agentic commerce needs a payment record that starts before checkout and ends after the outcome is known. That record should not expose every user prompt to every participant. It should preserve the minimum evidence each participant needs to perform its function: authentication, delegated authority, merchant and product scope, payment method, warnings, interventions, transaction state, and remedy path.
Data minimization is part of the KYA design. A shopping prompt can reveal sensitive preferences, health needs, business intentions, household details, or merchant strategy. KYA-ready systems should separate the evidence needed for fraud, dispute, and compliance review from data that would create unnecessary profiling or retention risk.
Common rails will matter. If issuers, acquirers, wallets, merchants, and agent providers all describe agent involvement differently, disputes will become a reconstruction exercise. A shared KYA file gives each participant a consistent way to ask: who sent the agent, what was it allowed to do, what did it actually do, and who owns the remedy when the result is wrong?
Practical KYA checklist
- Mark every payment flow where an AI agent searched, selected, prepared, submitted, or supported the transaction.
- Store a mandate reference that captures customer instruction, scope, spending cap, merchant constraints, expiration, and review conditions.
- Separate product discovery, ranking, merchant selection, checkout preparation, payment submission, support, and dispute handling into distinct permission classes.
- Require agent and merchant risk checks before payment submission, especially where stored payment details or wallet access are involved.
- Preserve warnings, interventions, denied actions, authentication results, transaction references, and post-payment outcomes in the audit trail.
- Limit sensitive prompt and purchase data to the participants and purposes that need it, with separate consent for additional sharing or reuse.
- Map the same agentic-commerce flow to local payment authentication, privacy, consumer protection, chargeback, fraud recovery, and recordkeeping rules before rollout.
Bottom line
The bank proposal makes KYA concrete for agentic commerce. A payment system cannot rely on a final authorization message when the real risk is whether an agent acted within the customer's delegated authority. The compliance file must show that this agent, acting for this principal, under this mandate, used this payment boundary, followed these warnings, produced this outcome, and left this dispute path. That is the audit trail agentic payments need before scale.
Source note: This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.