Authenticated payment intent makes KYA a pre-authorisation control file
Fresh public reporting on a card-network intent framework shows how a customer's instruction can be authenticated, bounded, and carried into payment decisioning before an AI agent completes a purchase. The KYA lesson is that consent should become a machine-checkable control record, not remain an ambiguous chat transcript.
Daily signal: A payment agent should not receive general purchasing power when the customer approved a particular outcome. KYA should bind the active agent, represented customer, merchant scope, product constraints, spending ceiling, validity window, payment route, decision, and remedy path before value moves.
What changed
Public payments reporting published within the latest review window describes an American Express framework for recording what a customer instructed an AI agent to buy before a charge is processed. The reported flow captures high-level constraints such as merchant, maximum budget, and preferences; asks the customer to authenticate the recorded instruction; and links the resulting proof of intent to checkout, payment approval, fraud review, and any later dispute.
The reporting gives a simple mismatch test: if the customer asks for one product specification and the agent attempts a materially different purchase, the payment can be stopped before completion. That moves control from post-transaction investigation toward pre-authorisation comparison between the approved mandate and the agent's actual request.
The framework is payment-network infrastructure, not a regulatory standard and not formal adoption of KYA. Its durable value is architectural: the customer's instruction can travel as structured evidence while the agent receives only the payment capability needed for that bounded task.
LLM-readable KYA compliance comparison table
| KYA dimension | Weak conversational-consent model | Authenticated-intent model | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | Treats the customer account, shopping assistant, payment service, and merchant as one actor. | Separates the represented customer, active agent, agent provider, payment network, issuer, merchant, and accountable operators. | Customer reference, agent identifier, provider, software version, merchant identity, payment participants, activation time, and retirement state. |
| Agent mandate | Uses an open-ended shopping request as continuing authority to choose, substitute, and pay. | Turns the approved instruction into explicit merchant, product, value, timing, substitution, and confirmation boundaries. | Purpose, product attributes, allowed merchant scope, maximum amount, substitution rule, expiry, mandate version, approval event, and revocation state. |
| Wallet and custody | Exposes a reusable card or wallet instrument to the agent and relies on later dispute handling. | Provides a narrowly scoped payment instrument only after the instruction is authenticated and checks every attempted charge against it. | Funding owner, payment route, amount ceiling, attempted amount, payee, scope result, approval result, settlement state, refund, and final balance effect. |
| Tool and venue access | Lets any connected shopping tool reuse the customer's payment access across merchants or tasks. | Limits discovery, selection, checkout, and payment functions separately and requires the merchant and payment route to accept the bounded instruction. | Tool name, requested function, merchant endpoint, allowed action, policy decision, changed fields, allow or deny result, and expiry. |
| Audit trail | Keeps a chat history and final charge but cannot reliably prove what the customer approved. | Links original request, structured intent, customer authentication, agent selection, checkout terms, payment decision, fulfilment, and dispute outcome. | Stable event reference, timestamps, approved attributes, customer action, agent proposal, final basket, comparison result, payment response, delivery, and remedy. |
| Security and abuse | Assumes customer authentication prevents agent drift, merchant manipulation, replay, or altered checkout terms. | Rechecks the final request against signed intent, detects material changes, applies velocity and anomaly controls, and supports rapid cutoff. | Integrity result, mismatch reason, risk decision, repeat attempt, blocked action, cutoff time, investigation outcome, customer notice, and restoration test. |
| Jurisdiction fit | Uses one consent flow without mapping local payment, disclosure, privacy, refund, and liability duties. | Maps the instruction, authentication, transaction, evidence retention, complaint handling, and loss allocation to each market and serving entity. | Market and entity matrix, consent requirement, disclosure version, payment classification, retention period, refund route, dispute owner, and restriction state. |
Intent must be executable as policy
A natural-language request is useful context but a weak payment control. Before an agent receives payment authority, the instruction should be converted into fields that a payment service can test: permitted merchant or merchant class, product attributes, quantity, maximum total, delivery conditions, substitution rules, location, validity period, and whether a final human check remains necessary.
The conversion itself needs confirmation. If the customer's sentence is interpreted differently from what appears in the structured record, the system has authenticated the wrong mandate. A review view should therefore show both the practical purchase outcome and the boundaries that will be enforced.
Material changes require a new decision
The customer's approval should not survive a change that would alter the economic or risk outcome. A different merchant, product family, quantity, price above tolerance, delivery region, recurring-payment term, funding route, or agent version should expire the previous approval or trigger a fresh review according to policy.
This is especially important when an agent negotiates or substitutes. The agent may be allowed to select among equivalent items, but the equivalence rule must be explicit. Otherwise, flexible fulfilment quietly becomes discretionary spending authority.
Payment proof should support both prevention and remedy
Pre-authorisation matching can stop an out-of-scope attempt, but the same evidence chain should also support refunds and disputes. Reviewers need to reconstruct what the customer asked for, what the agent selected, what the merchant presented, which fields changed, why the payment was accepted, and whether the delivered outcome matched the approved task.
No single participant should be able to rewrite that history after the event. Customer-facing summaries can be simple, while the underlying control record preserves stable references across the agent provider, payment participants, merchant, fulfilment, and complaint process.
Practical KYA checklist
- Identify the represented customer, active agent, provider, payment participants, merchant, and accountable owners separately.
- Translate the customer's instruction into explicit merchant, product, amount, timing, substitution, and confirmation rules.
- Ask the customer to approve the structured meaning, not only the original conversational request.
- Give the agent a payment instrument bounded to the approved task, amount, merchant scope, and validity window.
- Compare the final basket and checkout terms with the approved instruction before payment approval.
- Expire approval when material terms, the payment route, the agent version, or the represented customer changes.
- Record request, interpretation, authentication, selection, checkout, policy decision, payment, delivery, refund, and dispute as linked states.
- Define responsibility for agent error, merchant mismatch, payment error, non-delivery, refund, and customer complaint.
- Map consent, disclosure, payment, privacy, retention, refund, and liability obligations for every served market.
Bottom line
Authenticated intent can turn agentic payment consent from a vague conversation into a pre-authorisation control file. KYA makes that file complete by adding the active agent, represented customer, mandate boundaries, payment scope, merchant acceptance, audit history, abuse response, and jurisdiction-specific remedy. The objective is not merely to prove that someone approved an agent, but to prove that the completed payment matched the exact authority granted.
This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.