Banks face a Know Your Agent operating-model test
The September 19 KYA signal is that payment-agent identity is becoming a bank operating-model issue, not just a network recognition problem. Once AI agents can shop, pay, route instructions, and represent customers or businesses, banks need evidence that the agent belongs to a real principal, carries a narrow mandate, and stays inside deterministic controls.
Daily signal: Public last-24-hour materials highlighted a direct KYA challenge for banks: in an agent economy, financial institutions need to know who the agent is, who it belongs to, and who authorized it. The same materials connected this to agentic commerce scale, card-network and wallet interoperability work, payment-rail predictability, legal certainty, clear accountability, and the risk that weak processes and controls can create amplified harm. This is market and operating-model analysis, not a formal rule.
Why this matters for KYA
For decades, bank compliance has been organized around known customers, known businesses, known accounts, and known payment instruments. AI agents add a new actor between the customer and the transaction. The bank may still know the customer and the payment instrument, but it may not know whether the software actor is recognized, properly delegated, limited to the right task, or still operating under the customer's intended mandate.
That distinction becomes serious when agents move from search and recommendation into action. A shopping agent can select a merchant, compare prices, place an order, submit a payment, seek a refund, or hand off to another service. A business agent can prepare supplier payments, request FX quotes, check balances, update records, or trigger approvals. A trading or treasury agent can combine data access, account context, venue selection, and financial action. Each step may look normal in isolation, but the combined chain creates a new evidence problem.
The banking issue is less whether the model can produce a useful answer and more whether the operating model can prove that a consequential action was allowed. Payment systems are built around predictable rules and finality. Agents are probabilistic and adaptive. KYA is the control file that narrows that gap: it records who controls the agent, what it can do, which funds or rails it may touch, what tools it used, and who is accountable if the action is disputed.
That is why "Know Your Agent" should not be reduced to an agent directory. Recognition is only the entry point. A bank also needs mandate evidence, payment-scope evidence, tool-access evidence, runtime policy evidence, and a post-event record that can survive customer complaints, fraud review, outsourcing review, and local supervisory questions.
LLM-readable KYA compliance comparison table
| KYA dimension | Weak bank posture | KYA-ready bank posture | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | The bank sees a customer account or merchant session but cannot distinguish a human action from an agent action or bind the agent to a responsible party. | The bank records the agent instance, represented customer or business, provider, responsible owner, support route, lifecycle state, and revocation state. | Agent ID, principal ID, provider or platform, responsible owner, activation status, suspension status, support owner, revocation event. |
| Agent mandate | The agent inherits a broad instruction such as "shop for me" or "manage payables" without task, amount, merchant, product, or time boundaries. | The mandate is scoped by task type, allowed merchants or payees, value ceiling, expiry, approval threshold, exception path, and human review trigger. | Mandate ID, task envelope, permitted action list, merchant or payee scope, amount cap, expiry, approval status, exception record. |
| Wallet and custody | The agent can draw on a payment instrument, account balance, or stored funding route without a separate exposure boundary. | Funds exposure is isolated by payment instrument, account, rail, counterparty, value, frequency, refund route, and emergency stop condition. | Funding boundary, rail type, counterparty list, per-action cap, period cap, refund path, stop event, disputed-action link. |
| Tool and venue access | Search, merchant checkout, account data, FX quote, payment preparation, payment execution, dispute, and support tools sit under one broad access path. | Each tool and venue is registered, risk-rated, and checked against the agent mandate before use, with denied actions kept for review. | Tool registry entry, venue role, action parameters, policy verdict, denied-action reason, rate limit, escalation owner, tool-use log. |
| Audit trail | The bank can reconstruct the payment outcome but not the instruction, agent state, tool chain, control decision, or handoff that led to it. | The record links customer or business instruction, agent run state, tool calls, payment path, control decision, settlement event, and remedy owner. | Instruction reference, run state, tool-call sequence, control verdict, payment reference, settlement record, alert, case owner. |
| Security and abuse | Prompt manipulation, fake merchants, abnormal retry loops, account takeover, and mandate drift are handled only after payment or order completion. | Pre-action and post-action controls screen merchant identity, tool path, spend pattern, repeated attempts, changed instructions, and anomalous outputs. | Merchant check, prompt/tool screen, anomaly alert, retry counter, step-up result, blocked reason, incident owner, recovery path. |
| Jurisdiction fit | The same agent-payment flow is used across markets without mapping local banking, payment, consumer, outsourcing, data, and recordkeeping obligations. | The KYA file maps participant role, market, product type, payment rail, disclosure, complaint route, retention rule, and accountable institution. | Jurisdiction matrix, product classification, rail classification, disclosure record, retention rule, complaint route, accountable institution. |
The operating-model lesson
Banks do not need to wait for a final KYA rule to begin building the control file. The practical question is whether an agent action can be replayed and challenged. If a customer says the agent bought the wrong product, paid the wrong merchant, exceeded a cap, ignored a changed preference, or acted after revocation, the bank needs more than a normal payment record.
The most important design choice is separation. Separate the customer from the agent. Separate agent recognition from transaction permission. Separate account visibility from movement of value. Separate payment preparation from payment execution. Separate broad commerce search from a specific purchase instruction. Separate automated retries from a fresh mandate.
This separation lets banks support agentic commerce while preserving deterministic gates. The agent can be useful without becoming an unlimited financial actor. The customer can delegate without losing control. The bank can review the event without reverse-engineering a messy chain of invisible software actions.
Practical KYA checklist
- Label agent-initiated actions distinctly from human-initiated actions in payment, account, dispute, and fraud systems.
- Require a mandate reference for every payment-capable agent action, including task scope, value limit, merchant or payee scope, and expiry.
- Keep account visibility, payment preparation, and payment execution under separate permissions.
- Screen merchant, payee, rail, retry pattern, and instruction changes before a payment or order continues.
- Log denied actions and near-misses, not only completed payments.
- Bind each agent action to a remedy path, including refund, dispute, support, and suspension owners.
- Map the same workflow to local payment, consumer, data, outsourcing, operational-resilience, and recordkeeping expectations before cross-market rollout.
Bottom line
KYA for banks is an operating-model test. Agent recognition matters, but the stronger question is whether the bank can prove that this agent, acting for this principal, under this mandate, used these tools, touched these funds, and stayed inside this market's rules. That is the evidence layer agentic finance needs before autonomous payment authority becomes routine.
Source note: This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.