Know Your Agent (KYA) vs KYC: A Banking Control Framework

“Know Your Agent” is becoming the identity slogan of agentic finance. It is useful, but the slogan can hide more than it explains.

A bank does not only need to know which software agent arrived. It needs to know who stands behind it, what authority was delegated, which version is running, which credentials it may use, how the mandate can be revoked, and who carries the consequences when the action is wrong.

That is why KYA should not be framed as the new KYC. Identity proves which agent arrived. A mandate determines what it may do. Banking needs both, plus the existing controls that apply to the customer and business.

KYA Is an Operating Model, Not New KYC

Know Your Customer (KYC) and Know Your Business (KYB) are established parts of regulated customer due diligence. Know Your Agent (KYA) is an emerging industry term for identifying and governing software agents that act for people or organizations.

NIST’s concept paper on software-agent identity and authority treats the problem as more than authentication. It asks how a relying party can determine an agent’s identity, the person or entity it represents, and the authority attached to a particular interaction. The OpenID Foundation’s agentic identity whitepaper similarly explores delegation, credentials, and authorization in multi-agent systems.

Neither source creates a new statutory process called KYA or removes existing KYC, KYB, AML, sanctions, fraud, or consumer-protection duties. The practical reading is simpler: KYA is a control layer for software acting on behalf of an already accountable principal.

The Five Identities Behind One Agent

An agent request may appear to come from one actor. In production, at least five identities can matter.

1. The principal

The principal is the person or legal entity on whose behalf the agent acts. It might be a consumer asking an assistant to compare mortgages or a company allowing a procurement agent to buy market data.

2. The operator

The operator runs or deploys the agent. The principal and operator may be the same organization, but they do not have to be. A bank customer could use an agent supplied by a third-party platform.

3. The agent instance

The specific runtime instance needs a stable, auditable identifier. “Finance bot” is not enough when several instances, tenants, environments, or workflows share a name.

4. The model and software version

The model, system prompt, tool code, policy engine, and release version can alter behavior. An identity record should be able to distinguish the version that passed testing from a later or modified build.

5. The credential and tool

An agent can present an API key, OAuth token, wallet signer, or workload identity. That credential identifies or authorizes a technical caller; it does not by itself prove that the requested transaction matches the principal’s intent.

KYA fails when these layers collapse into one opaque “agent ID.”

KYA vs KYC vs KYB

Control	Primary subject	Core question	What it does not prove
KYC	Individual customer	Who is this person and what risk is associated with the relationship?	That a software request is authorized
KYB	Legal entity	Is this business legitimate and who owns or controls it?	That this agent instance may bind it
KYA	Software agent and delegation chain	Which agent is acting, for whom, under what mandate and version?	The customer is low-risk or the transaction is correct

The controls complement one another. A verified company can still deploy a compromised agent. A cryptographically identified agent can still act outside its mandate. A correctly authorized payment can still be fraudulent because the human principal was deceived.

The Cloud Security Alliance’s Agentic Trust Framework applies a zero-trust idea to agents: verify continuously and make authority explicit. That is a more useful foundation than treating KYA as a one-time onboarding document.

Identity Is Not Authorization

Suppose a bank verifies that a request came from agent AP-4821, operated by Company A for Customer B. That is valuable identity evidence. It still leaves several authorization questions:

• May the agent read balances, initiate a payment, or both?
• Which accounts and counterparties are in scope?
• What amount, currency, time window, and frequency are permitted?
• Does the principal need to approve a new beneficiary?
• Can the agent delegate the task to another agent?
• What happens if the model or tool version changes?

Authorization should be transaction-specific enough to answer those questions without asking the model to police itself.

A robust mandate can include:

Principal: Company A treasury
Agent instance: treasury-procurement-prod-07
Purpose: purchase approved financial datasets
Allowed merchants: registry IDs 14, 28, 31
Per-transaction maximum: USD 100
Daily aggregate maximum: USD 300
Expiry: 2026-08-24T18:00:00Z
Human approval: required for a new merchant or recurring charge
Delegation: prohibited

This kind of structure turns a vague instruction into enforceable policy.

From Mandate to Deterministic Execution

A bank-grade agent flow can be organized as a chain:

1. Identity: establish the principal, operator, agent instance, version, and credential.
2. Mandate: capture the permitted purpose, scope, limits, duration, and delegation rights.
3. Policy: evaluate the request against institutional rules and the customer’s mandate.
4. Deterministic execution: construct and validate the exact transaction outside free-form model text.
5. Monitoring: observe anomalies, cumulative exposure, counterparties, and failed attempts.
6. Revocation: stop the credential, mandate, session, or agent instance quickly.
7. Evidence: preserve the request, decision, approval, execution, and result.
8. Dispute: provide a route to investigate and remedy an incorrect action.

The model can propose a transaction. A deterministic service should verify typed fields, account state, beneficiary, amount, currency, and policy before execution. This is the same principle behind infrastructure-enforced limits in AWS AgentCore Payments.

Monitoring, Revocation, and Evidence

Traditional identity systems often focus on issuing a credential. Agents need lifecycle controls because their behavior and environment can change while the credential remains valid.

Monitor the mandate, not only the login

A successful authentication event does not make the next thousand actions normal. Monitor transaction patterns, new tools, new counterparties, time-of-day changes, repeated failures, and attempts just below a threshold.

Revoke at more than one level

A bank may need to revoke:

• one task or payment session;
• one agent instance;
• one model or software version;
• one operator integration;
• one principal mandate;
• one wallet or API credential.

If the only option is to close the customer’s entire relationship, the control is too coarse.

Preserve evidence that a reviewer can read

Logs should connect the human or business mandate to the final financial action. Record the source request, relevant input data, policy version, agent and tool versions, approvals, constructed transaction, execution response, and any later reversal.

The goal is not to store every hidden model calculation. It is to preserve the facts needed to reproduce the control decision. Our financial-analysis controls checklist uses the same evidence-first approach for non-transactional work.

Who Is Liable When an Agent Acts

Calling an agent an “economic actor” does not make it a legal person. Liability depends on the jurisdiction, contract, regulated activity, agency relationship, product design, and facts of the incident.

Several parties may be involved:

• the principal who gave the mandate;
• the company that deployed the agent;
• the platform or model provider;
• the bank or payment provider that accepted the instruction;
• the merchant or counterparty;
• a third party that compromised the workflow.

KYA can make that chain visible. It does not decide the legal outcome by itself.

The IMF’s work on agentic AI and payments highlights broader questions around governance, risk allocation, and payment-system adaptation. Banks should therefore avoid product language suggesting the agent independently owns an account or bears responsibility. The accountable human and institutional relationships must remain explicit.

A Bank Deployment Checklist

Identity and provenance

• Identify the principal, operator, agent instance, model, software version, and credential.
• Use workload or device-bound credentials where appropriate.
• Attest approved code and configuration before granting a sensitive tool.

Mandate and policy

• Define purpose, accounts, data, counterparties, amount, frequency, duration, and delegation.
• Place transaction limits in policy infrastructure, not only in prompts.
• Require step-up authentication or human approval for higher-risk changes.

Execution

• Translate model proposals into a typed transaction schema.
• Validate beneficiary, amount, currency, account state, and sanctions controls deterministically.
• Make retry and idempotency behavior explicit.

Operations

• Monitor aggregate exposure and behavioral anomalies.
• Support narrow, immediate revocation.
• Reconcile every financial action with its authorization and outcome.
• Test incident, dispute, and recovery procedures before launch.

This operating model also improves the infrastructure of the agentic economy. Markets can accept software callers only when identity, authority, and evidence travel with the request.

Frequently Asked Questions

What does Know Your Agent mean in banking?

KYA is an emerging framework for identifying a software agent, the principal and operator behind it, its version and credentials, and the mandate under which it acts.

Does KYA replace KYC or KYB?

No. KYC and KYB address the person or business relationship. KYA adds controls for software acting on that party’s behalf.

Is an agent identity enough to authorize a payment?

No. The bank also needs a valid mandate, transaction scope, policy decision, deterministic validation, and evidence of the resulting action.

Who is liable for an AI agent’s transaction?

There is no universal answer. Liability depends on law, contracts, delegation, product controls, and the facts. KYA helps preserve the chain of responsibility but does not replace legal analysis.