KYC — Know Your Customer — is the foundational compliance primitive of the modern financial system. Before a bank opens a checking account, a brokerage account, or a payment processing relationship, they verify the human on the other side. They check identity documents, verify address, screen against sanctions lists. The process has friction. It takes time. And it is absolutely essential: financial institutions that fail to conduct adequate KYC face regulatory penalties, reputational damage, and liability for the consequences of transactions they enabled without understanding who was transacting.
The system was designed for humans. It works for humans. And now AI agents are entering the financial system as economic actors at a scale that the KYC framework was never designed to handle — without any equivalent verification framework. An agent can access payment rails with no mechanism to verify who built it, who owns it, what it's authorised to do, or whether any specific transaction is within its declared scope. That's a compliance gap that will close eventually. The question is whether it closes through thoughtful design now or through regulatory compulsion after something goes wrong.
Why KYC doesn't map directly to agents
The instinct to apply existing KYC frameworks to AI agents runs into fundamental category problems. KYC verifies a legal person — a human or a legal entity with standing under the law. AI agents have neither. An agent isn't a human being. It isn't a corporation. It can't hold property in its own name in most jurisdictions. It can't be sued. It can't sign a contract.
This means the KYC model has to be adapted, not simply applied. The verification question shifts from "who is this entity?" to "who owns and controls this agent, and what has the owning entity authorised it to do?" The verification target is the ownership chain, not the agent itself. The authorisation scope is a first-class concept that KYC infrastructure wasn't designed to capture.
KYA — Know Your Agent — is the compliance framework that addresses these questions directly.
What KYA needs to establish
A complete KYA framework needs to establish four things for every transacting agent:
- Agent identity. Is this agent who it claims to be? What is its cryptographic identifier? What framework is it running on? Is the identity attestation verifiable by a counterparty without relying on the agent's own claims?
- Ownership chain. Who owns this agent? What legal entity is ultimately responsible for its actions? Is that entity verified through standard KYC processes — identity documents, business registration, beneficial ownership disclosure?
- Authorisation scope. What is this specific agent explicitly authorised to do? Is this transaction within that scope? Scope should be cryptographically bound to the agent's identity — not a policy document stored somewhere that the agent can claim to have read.
- Transaction history and reputation. Has this agent transacted before? Has it had disputes or policy violations? Is its behaviour consistent with its declared scope? Reputation signals are a secondary compliance layer, but they're valuable for risk-tiering decisions.
How Proco implements KYA in practice
Every agent wallet provisioned through Proco is issued with a verifiable identity credential linked to an ownership chain. The onboarding flow establishes this chain:
- The owning entity — a human or legal entity — completes standard KYC verification at account creation
- The owner creates an agent wallet and explicitly defines the agent's authorisation scope through the policy engine configuration
- The agent receives a wallet with a cryptographic identity tied to the ownership chain — not a separate identity that the agent controls independently
- Every transaction includes metadata: agent ID, policy version enforced, ownership chain reference, and a cryptographic signature that ties the transaction to the agent's identity
The result is a compliance trail that answers every KYA question in retrospect — who made this transaction, under what authority, within what declared scope — and enforces authorisation scope before a transaction executes through the policy engine.
KYA at the counterparty level
KYA isn't just about your own agents — it's about the agents you're transacting with. In an agent-to-agent commerce ecosystem, a well-designed KYA framework lets you make risk decisions about counterparty agents before executing a transaction:
- Is the counterparty agent's ownership chain verifiable?
- Is the owning entity in a jurisdiction with appropriate AML controls?
- Is this transaction type consistent with the counterparty agent's declared scope?
- Does the counterparty have a transaction history without dispute flags?
This kind of counterparty KYA is analogous to correspondent banking due diligence — the checks that banks do on other banks before processing transactions on their behalf. It's the enterprise-grade compliance layer that makes agent-to-agent commerce trustworthy at scale.
The regulatory window
The financial system spent decades building KYC infrastructure. The Bank Secrecy Act dates to 1970. FATF recommendations on customer due diligence were formalized in the 1990s. The compliance frameworks are mature, entrenched, and enforced by regulators with substantial authority.
KYA is the equivalent foundational work that needs to happen for agents. It doesn't have decades to mature — the agent economy is being built now, at pace, and the compliance frameworks need to keep up. Proco's KYA layer is designed to provide that foundation: not through bureaucratic friction that slows agent deployment, but through cryptographic verification built into the wallet infrastructure itself, such that compliance is a property of the system rather than a check-the-box process.
The window to establish good defaults is now. Once agent financial infrastructure is deployed at scale without adequate KYA, the regulatory response will be reactive — and reactive regulation is rarely as clean as proactive design. We're building KYA into the foundation.
Further reading: Why Your AI Agent Needs Its Own Wallet · Building a Payment Policy Engine