From KYC to KYA: The Identity Stack Banks Need Before Agents Can Touch Money

For decades, banks have been getting better at answering one question: who is this customer? KYC, sanctions screening, device fingerprinting, behavioral analytics and fraud controls all exist to confirm that a person or business is who they say they are.

Agentic AI breaks the assumption underneath all of that.

When an autonomous agent sends a payment, applies for credit, rebalances a portfolio or changes account settings, the one doing the acting isn’t just a human customer anymore. It’s software running on delegated authority, using credentials, calling tools and making decisions that carry real financial consequences. Banks need a new identity and authorization layer for this, and I’d call it Know Your Agent (KYA).

KYA doesn’t replace KYC. It extends KYC to a world where the customer’s software can act for them.

The Wire Nobody “Made”

Picture a treasury agent working for a mid-sized company. It notices a supplier invoice is due tomorrow, checks the cash position, verifies the counterparty and sends a $250,000 wire.

Now look at it from the bank’s side. You’d want to know:

Which human or legal entity authorized the transfer?
Which agent initiated it?
What model, version and software environment made the call?
What tools and accounts could the agent reach?
Was it allowed to move this amount to this beneficiary?
Was the delegation still valid at the moment of execution?
Can the bank prove all of this later?

Traditional KYC answers the first question. It’s silent on the rest.

That gap matters more every month. The OCC’s November 2026 supervisory framework for banks’ use of “super intelligence,” which covers generative and agentic AI, tells examiners to weigh things like the potential consequences of an agent failing or being misused, the transfer of agency, and how much human oversight exists.

KYC Was Built for Humans

The classic banking identity model is a simple chain:

Human → credential → account → transaction

A customer proves who they are, the bank issues credentials, access controls tie that person to an account, fraud systems watch their behavior, and audit logs point back to a person or session.

Agentic banking adds several links:

Human → agent → model/tool → credential → account → transaction

Every new link is a place for risk to creep in. An agent can be over-privileged. Its credentials might be reused across tasks. The authority it was given may be out of date. It can be hard to trace an action back to a specific principal, task or model version. And an agent’s behavior can look perfectly fine in isolation while being one step in a fraudulent or mistaken sequence.

The problem isn’t just that AI makes mistakes. It’s that an agent can act, and banking has always insisted that the ability to act be authenticated, authorized, monitored and revocable.

What Agentic Banking Changes

Banking control	Human-era assumption	Agentic-era reality
Identity	A verified person uses their own credentials	An agent may act for a person, business, vendor, or another agent
Authorization	A user role determines permissions	A task, tool scope, account, amount, and delegation determine permissions
Auditability	A user session is traceable	Actions must trace to agent, principal, delegation, model version, and tool call
Fraud controls	Systems monitor human behavior	Systems must monitor non-human action patterns, escalation, and credential reuse
Revocation	Disable a user or card	Revoke an agent credential, delegation, tool scope, or active task
Accountability	A person is responsible	A named human or institution remains accountable for agent outcomes

The OCC framework doesn’t create a separate category of AI risk, and it doesn’t ask banks to set a separate AI risk appetite. What it does stress is that controls should scale with the potential consequences of an agent’s failure or misuse, and that risk classification can factor in agency transfer and human oversight.

Put simply, an assistant that summarizes market data and an agent that can move money are not the same risk.

Enter KYA

Know Your Agent (KYA) is the bank-grade process of establishing the following, both before and during an agent’s transaction:

Who the agent is: a cryptographically verifiable identity, not just an API key.
Whom it acts for: the verified person or legal entity that delegated authority.
What it may do: narrowly scoped permissions for payments, credit applications, account changes, data access or portfolio actions.
What it can touch: the accounts, counterparties, data domains, tools and systems it’s allowed to use.
How far it can go: dollar thresholds, frequency limits, time windows and escalation rules.
Whether it can still be trusted: credential health, attestation, revocation status, anomaly signals and vendor integrity.

Here’s the shorthand I like:

KYC asks who you are. KYA asks who authorized this machine, what it may do, and whether that authority is still valid.

KYA isn’t a formal regulatory term yet, and no framework mandates it. But the OCC’s framework makes agent identity, delegation, authentication, permitted tool use, monitoring, velocity limits, disputes, suspension and revocation all fair game for supervisors.

The KYA Stack

“Agent security” isn’t one product you can buy. It’s a stack of controls that have to work together.

Agent Identity

Any agent that does something consequential needs a durable, verifiable identity.

That identity should be separate from a customer password, an employee login or a static API key. It should include:

A cryptographic identity, such as a key pair or a platform-issued agent identifier.
Hardware, secure-enclave or runtime attestation where that’s feasible.
Software provenance: vendor, code signature, model version, deployment environment and integrity status.
A registration record naming the agent’s owner, principal, purpose, risk tier and lifecycle status.
A unique identity the bank can suspend or revoke without touching the customer’s normal banking credentials.

The OCC framework also points to the importance of banks understanding what they can see about a provider’s agent: its defined authority, identity, permitted tool use, data use and escalation limits.

Delegation

An agent shouldn’t have authority just because it can reach an API.

KYA calls for an explicit delegation model:

Verified principal: the customer, business, treasury team, employee or authorized third party the agent works for.
Delegation grant: a precise statement of what the agent can do, for how long and under what conditions.
Consent evidence: proof that the principal approved high-risk actions, recurring mandates or standing instructions.
Delegation chain: visibility into cases where one agent calls another agent or a vendor service.
Revocation: the ability to end authority, credentials and active sessions immediately.

It’s the difference between “the agent has an API key” and “the agent holds a revocable, auditable mandate from a verified principal.”

Authorization

Role-based access control doesn’t go far enough here.

A human employee might hold a broad “payments” role. An agent should get a task-bound authorization: permission to do one defined kind of action, within set limits, for a set period.

Useful controls include:

Least-privilege scopes, such as payments.read, payments.initiate, credit.apply or portfolio.rebalance.
Transaction-level limits: maximum amount, beneficiary allowlists, currencies, time windows and approval thresholds.
Tool-level permissions covering which APIs, internal systems, files and data stores the agent can call.
Context-aware rules that take in risk score, account state, device posture, counterparty reputation and anomaly signals.
Human-in-the-loop gates for anything irreversible or high-consequence.

The OCC’s risk-based approach points the same way: the more damage an agent’s failure or misuse could do, the tighter the controls should be.

JWT-Bound Authorization Trails

One practical way to do KYA is with short-lived, cryptographically signed tokens, such as JSON Web Tokens (JWTs), that tie an action to the context in which it was authorized.

A JWT won’t solve agent security on its own. What it can do is create a verifiable, expiring, revocable trail linking a transaction to:

The agent identity.
The principal the agent acted for.
The delegation grant.
The permitted action or scope.
The task or transaction ID.
Account and counterparty constraints.
Expiration and revocation references.
Model or agent version and attestation claims.
A policy decision or human approval reference.

A simplified example:

{
  "sub": "agent:acme-treasury-bot-7f21",
  "act": { "sub": "user:customer-8842" },
  "azp": "bank-payments-api",
  "scope": "payments:initiate",
  "delegation_id": "dlg_9a81",
  "task_id": "task_5520",
  "max_amount": 250000,
  "allowed_counterparties": ["vendor_4417"],
  "model_version": "treasury-agent-v4.2",
  "attestation": "verified",
  "exp": 1790000000,
  "jti": "unique-token-id"
}

With a structure like this, the bank can ask something much sharper than “did someone with valid credentials make this request?”

It can ask: “Did this specific, attested agent, acting under this specific delegation, have the authority to start this specific payment, to this specific counterparty, at this specific time?”

Why Static API Keys Fail

A static API key answers exactly one question: does this caller have the secret?

It tells you nothing about:

Which principal authorized this particular transaction.
What task the agent was doing.
Which model version made the decision.
Whether the agent’s runtime environment was attested.
Whether the delegation was still valid when the action happened.
Whether the key could have leaked, been replayed or been used outside its intended scope.
Whether the bank can revoke this one agent without breaking every integration that shares the credential.

The OCC’s cybersecurity discussion treats agent identities and credentials much like users with elevated system access. That’s a quiet warning that broad, static credentials are a bad fit for consequential agent activity.

For high-risk actions, the credential should be a bounded representation of authority, not a permanent master key.

A KYA Transaction Flow

A bank-ready KYA workflow could look like this:

Register the agent in an internal or federated agent registry.
Verify the principal through existing KYC, AML, account-ownership and authorization controls.
Issue a delegation grant that defines permitted actions, limits, duration and approval requirements.
Authenticate the agent with a cryptographic credential and, where it makes sense, runtime attestation.
Bind authorization to the task with a short-lived JWT or an equivalent signed token.
Evaluate the transaction against fraud, sanctions, credit, liquidity and policy controls.
Execute or escalate depending on risk tier and human-approval thresholds.
Record the evidence in an immutable, machine-readable audit trail.
Monitor continuously for anomalies, scope drift, credential compromise and unexpected behavior.
Revoke instantly when consent, policy, trust or risk conditions change.

The aim isn’t to slow every agent action down with bureaucracy. It’s to make the high-consequence ones provable, bounded and, where possible, reversible.

What Banks Should Build First

Banks don’t have to wait for a formal KYA mandate to start on the underlying infrastructure.

A sensible order of work:

Create an agent inventory. Find every internal, customer-facing, vendor and third-party agent that touches bank systems.
Classify agents by consequence. Separate read-only research from payment initiation, credit decisions, account control and portfolio management.
Replace shared credentials with per-agent identities. No long-lived, broadly scoped API keys for anything consequential.
Make delegation a first-class object. Every agent mandate gets an owner, scope, expiry, approval record and revocation path.
Use short-lived, scoped tokens. Tie permissions to the task, principal, account, amount and counterparty.
Build fraud controls for agents. Watch velocity, new beneficiaries, instruction drift, tool-call anomalies and escalation patterns.
Design kill switches. Be able to suspend agents, revoke credentials, cancel pending transactions and preserve forensic evidence.
Make audit logs machine-readable. Connect every financial action to agent identity, delegation, authorization, model version and human oversight.

The Compliance Trap

It would be wrong to say the OCC has issued “new KYA rules.”

The OCC’s November 2026 bulletin describes its framework as a resource for examiners. It isn’t a set of supervisory expectations, enforceable standards or prescriptive requirements, and banks aren’t expected to use it to assess their own risk management for these systems.

Likewise, the revised model-risk guidance from the OCC, the Federal Reserve and the FDIC in April 2026 explicitly leaves out generative and agentic AI models, calling them novel and fast-changing. It also says that not following that guidance won’t lead to supervisory criticism.

None of that makes agent identity unimportant. If anything, it strengthens the case:

KYA is not yet a regulatory mandate. It is the engineering and risk-management response to a supervisory reality that is already moving toward agent-level accountability.

Banks that deploy high-consequence agents will end up needing KYA-like controls anyway, because their fraud, operational-risk, audit and customer-protection teams will demand them, whether or not a regulator ever uses the term.

The Strategic Takeaway

The next identity challenge in banking isn’t just verifying another human. It’s verifying that a machine is authorized to act for a human, within a defined scope, running trustworthy software, and leaving a trail that holds up under audit, dispute and fraud investigation.

Banks that treat agents as first-class principals, with cryptographic identity, explicit delegation, scoped authorization and instant revocation, will be able to roll out agentic finance safely.

Banks that keep treating agents like ordinary API users will eventually run into a harder question:

If your customer’s software can move money, who exactly did the bank trust?