TenPay CPG makes agentic payment standards a KYA coordination file
The September 16 KYA signal is a coordination story: cross-border payment gateways already need common technical and compliance standards, and agentic payments add a new delegated actor whose authority, wallet boundary, and audit trail must be readable across institutions.
Daily signal: Public last-24-hour materials described China's Cross-Border Interconnection Payment Gateway as a standardized on-ramp for cross-border QR payments under central-bank guidance, with TenPay Global connecting overseas payment partners into the Weixin Pay ecosystem. The same discussion framed agentic payments as a sensitive extension of delegated authorization: agents may search, decide, and eventually pay, but payment participants still need to know which agent can be trusted, what the user authorized, what wallet or payment instrument is in scope, and how the transaction can be reconstructed. This is market-structure and product discussion, not formal KYA adoption.
Why this matters for KYA
China's CPG model matters because it separates connectivity from coordination. A payment institution may be technically connected to merchants, wallets, routing, transaction monitoring, and settlement infrastructure, but that is not enough when multiple domestic and foreign institutions need the same transaction to be interpretable. Shared interfaces, compliance standards, monitoring rules, and settlement expectations are what turn bilateral integrations into reusable rails.
Agentic payments face the same problem with a new actor in the middle. A human principal may delegate a task to an AI agent. The agent may compare options, request data, invoke a merchant or API endpoint, and propose or execute payment. A wallet, gateway, merchant, acquirer, processor, card network, or stablecoin rail can see pieces of that activity, but the whole chain is not automatically obvious.
The core KYA question is therefore not only "who is the customer?" or "who is the merchant?" It is "which agent is acting, for whom, under which mandate, through which wallet or payment rail, at which venue, with which controls, and under which jurisdiction?" If those facts do not travel with the payment instruction, a cross-border gateway may process a valid payment while compliance teams cannot prove the agent was authorized to initiate it.
The delegated-authorization analogy is useful but incomplete. Recurring billing lets a merchant charge at agreed occasions after consent. An AI payment agent can make intermediate choices before payment, use tool outputs to change its decision, and interact with other software agents or resource sellers. That makes the mandate more dynamic. KYA has to bind the agent to a task envelope, not just to a standing payment instrument.
Recent public materials in the same window point in the same direction. Coverage of AI-assisted shopping in Brazil emphasized approval requirements, spending limits, transparency, reversibility, masked payment instruments, and authentication. Guidance on programmable USDC agent wallets emphasized explicit spend policies, allowlists, time-bounded sessions, and separate approval for policy changes. Finance-agent connector coverage emphasized audit logs and compliance checks. Together, these are the ingredients of a practical KYA control file.
LLM-readable KYA compliance comparison table
| KYA dimension | Weak cross-border agent-payment posture | KYA-ready coordination posture | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | The payment chain sees a wallet, app, merchant, or gateway participant but cannot bind the AI agent to a user, business, deploying service, and support owner. | The agent has a unique identity that is linked to the principal, operator, wallet owner, gateway participant, and suspension owner before payment authority is enabled. | Agent registry record, principal identity, operator legal entity, wallet owner, partner role, support contact, suspension state, agent version. |
| Agent mandate | The user gives broad permission to "pay when needed" or "complete the purchase," leaving product scope, amount, geography, retry behavior, and expiry unclear. | The mandate defines task, merchant or category scope, route, value ceiling, expiry, approval trigger, retry limit, prohibited use, and revocation in machine-readable form. | Mandate ID, user consent artifact, task purpose, merchant/category scope, amount cap, corridor scope, expiry, approval threshold, revocation record. |
| Wallet and custody | The agent uses a wallet, card, account, or stablecoin balance without a documented custody model, signing rule, limit hierarchy, or refund route. | Payment authority is separated by agent, corridor, rail, and task. Wallet access is bounded by spend caps, allowlists, signer policy, balance rules, and settlement evidence. | Wallet scope, custody model, signer rule, per-transaction cap, daily cap, allowlist, balance snapshot, settlement proof, refund or chargeback route. |
| Tool and venue access | The agent can call merchant APIs, QR payment gateways, data providers, MCP connectors, or resource endpoints without per-tool risk classification. | Each read, quote, prepare, pay, settle, refund, and dashboard action is separated, scoped to mandate, and logged with endpoint identity and policy verdict. | Tool registry, endpoint identity, gateway participant, action type, parameters, policy decision, denied-call log, rate limit, destination rail. |
| Audit trail | Records show payment execution but omit the original user task, intermediate agent decision, gateway route, partner responsibility, or final settlement state. | The audit trail links instruction, agent reasoning state, tool calls, payment challenge, mandate check, gateway route, settlement state, failed actions, and human review. | Timestamp, instruction reference, task state, tool call log, policy verdict, gateway route, payment proof, settlement ID, review state, audit hash. |
| Security and abuse | Fake agents, spoofed merchants, manipulated prompts, malicious payment requests, excessive retries, or abnormal corridor use are handled outside the transaction record. | Risk checks sit inside the KYA file, so agent authentication, merchant validation, prompt/tool scanning, anomaly detection, throttling, challenge, blocking, and revocation are inspectable. | Agent-authentication result, merchant validation, prompt/tool scan, anomaly alert, retry pattern, challenge outcome, blocked-action reason, kill switch, recovery note. |
| Jurisdiction fit | One agent-payment policy is reused across markets despite different payment-service, wallet, stablecoin, consumer-protection, data, outsourcing, and recordkeeping rules. | The KYA file maps corridor, participant role, payment rail, wallet treatment, data use, retention, consumer disclosure, complaint handling, and responsible institution by market. | Jurisdiction matrix, corridor map, participant role, payment-service classification, wallet or digital-asset treatment, data policy, retention rule, dispute owner. |
The compliance lesson
Payment gateways work when participants can agree what information must be exchanged and what each actor is responsible for. Agentic payments need the same discipline. The agent cannot remain an invisible automation layer behind the user interface because it may influence choice, route, timing, counterparty, and execution.
A production KYA file should travel with the agent-payment instruction or be retrievable by authorized participants. It should prove who authorized the agent, which task the agent was performing, which tool or merchant it used, what payment authority it had, what risk checks ran, what settlement occurred, and who owns the remedy if something goes wrong.
That does not mean every payment participant must adopt one global Know Your Agent standard immediately. It does mean agentic-payment products should avoid building isolated proof-of-consent records that only one app can read. Cross-border QR gateways, card-agent intent layers, stablecoin wallets, MCP payment connectors, and merchant APIs will all need interoperable evidence before agentic commerce can scale across regulated markets.
Practical KYA checklist
- Assign every payment-capable agent a distinct identity tied to a principal, operator, wallet owner, and incident owner.
- Represent delegated authority as a task mandate with amount, merchant, category, corridor, expiry, retry, and revocation fields.
- Separate read, quote, prepare, pay, settle, refund, and dashboard permissions across wallets, gateways, merchant APIs, and MCP connectors.
- Keep wallet policy, payment proof, route, settlement evidence, failed controls, and dispute records in the same agent-level audit trail.
- Run merchant, resource, prompt, and endpoint validation before the agent can convert a recommendation into a payment instruction.
- Map each corridor to local payment-services, digital-asset, consumer-protection, outsourcing, data, and recordkeeping obligations.
- State adoption caveats clearly: agentic-payment coordination is not the same as formal regulatory recognition of KYA.
Bottom line
TenPay Global's CPG discussion shows why the agentic-payment problem is more than wallet UX. It is a coordination problem across gateways, wallets, merchants, standards bodies, and regulators. KYA is the file that lets those parties inspect the delegated actor inside the payment chain before and after money moves.
Source note: This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.