What Is Know Your Agent (KYA)? A Guide for Payment and Fintech Teams

Know Your Agent (KYA) is the practice of verifying an AI agent before you let it act: what the agent is, which person or business it acts for, what it is authorized to do, and whether every action can be traced and revoked. It extends KYC and KYB to software that opens accounts, calls APIs, and moves money on someone's behalf.

Runtime is the AI agent harness for payment and fintech teams. This guide explains KYA in plain terms, how it differs from KYC and KYB, and how payment teams can apply it on both sides: to the agents that reach them, and to the agents they run.

Why KYA matters now

Agents now open accounts, fill out onboarding forms, check out, call APIs, answer support tickets, and send emails. Card networks have built programs for agent-initiated payments, and identity vendors have launched products to verify the agents themselves.

For a payments company, that creates two new questions.

• Outside agents transacting with you. An agent hits your checkout, your API, your support inbox, or your merchant onboarding flow. Is it a legitimate agent acting for a real, verified customer, or a bot running fraud at scale?
• Your own agents acting for you. Your team deploys agents to investigate payouts, reply to merchants, or prepare a response to your sponsor bank. Who are they, what can they touch, and who answers for what they did?

Both questions come down to the same thing KYC answered for people: know who you are dealing with, and keep the record.

KYA vs KYC vs KYB

KYA does not replace KYC or KYB. It depends on them. An agent is only as trustworthy as the verified person or business it is bound to.

What a KYA check covers

• Identity of the agent. A stable, verifiable identity for the agent itself, usually a cryptographic credential or signature, so you can tell one agent from another and from an anonymous bot.
• The principal it acts for. The human or business behind the agent, linked to a completed KYC or KYB check. This is where accountability lives.
• Delegated authority, scope, and limits. What the principal allowed the agent to do: browse, buy, open an account, move up to a set amount, act only with certain merchants or for a limited time.
• Credentials and attestation. Proof that the agent's claims are real: signed requests, scoped tokens, or a credential from a network or verification provider.
• Behavior and monitoring. Whether the agent's activity matches its stated purpose, checked continuously, because a verified agent can still be compromised or misused.
• Audit trail and revocation. A record of what the agent did under which authority, and a way to cut off its access when consent is withdrawn or something looks wrong.

Two sides of KYA for payment teams

Inbound: due diligence on other companies' agents. Agents from other platforms will reach your checkout, APIs, support channels, and onboarding flow. Your risk and compliance teams need a policy for them, the same way they have one for new merchants: which signals and credentials you accept, how you check the principal, which actions need extra verification, and when a human reviews. That review is real work, and it lands on the same analysts already working KYB and fraud queues. Our guide on KYB and KYC review agents covers the onboarding side of that queue.

Outbound: your own agents. When your agents act for you, they need what you would demand from anyone else's: their own identity, permissions scoped to the job, approvals before sensitive actions, and an audit trail your sponsor bank and auditors will accept. An agent sharing a teammate's login, or holding an API key with full access, fails that test.

How the industry is approaching it

KYA is still taking shape, and the term is used in slightly different ways. Here is how some of the companies shaping it describe their work.

• Ant International, Mastercard, and Visa announced a collaboration on a Know Your Agent interoperability framework in September 2026. They describe it as helping card networks, wallets, agent platforms, and marketplaces onboard and identify agents across networks, with a focus on operator traceability, shared certification requirements, and continuous transaction monitoring. Each brings its own protocol: Visa's Trusted Agent Protocol, Mastercard's Verifiable Intent, and Ant International's Agentic Mobile Protocol.
• Visa describes its Trusted Agent Protocol, built on Visa Intelligent Commerce, as a way for merchants to verify a trusted agent and its intent using cryptographic signatures that are merchant-specific, purpose-bound, and time-limited.
• Mastercard says that under Agent Pay, AI agents are registered and verified before they make payments for their users, using Mastercard Agentic Tokens.
• Google describes its Agent Payments Protocol (AP2) as using Mandates, cryptographically signed digital contracts backed by verifiable credentials, as proof of a user's instructions.
• Stripe and OpenAI co-developed the Agentic Commerce Protocol. Stripe's Shared Payment Token lets an agent start a payment without exposing the buyer's credentials, scoped to a specific merchant and cart total.
• Cloudflare recognizes "signed agents" whose requests are signed through Web Bot Auth, an approach based on HTTP message signatures.
• Skyfire launched KYAPay, an open protocol that pairs a signed agent identity token carrying verified information about the agent's owner with a payment token.
• Sumsub defines KYA as a risk-based approach that gives an agent an identity, binds it to a responsible human or organization, and enforces policy, oversight, and auditability.
• Persona frames KYA around three questions: is this an agent or a human, who are the humans behind it, and can they be trusted.
• Trulioo describes KYA as verifying the agent developer, locking the agent code, capturing user permission, issuing a Digital Agent Passport, and checking status continuously.

The common thread: tie every agent to an accountable principal, limit what it can do, and keep checking.

Where Runtime enters the picture

Networks and identity vendors give you signals and credentials. Someone still has to apply your policy to them, investigate the edge cases, and keep your own agents in line. Runtime helps on both sides.

Agents that do due diligence on other agents. Teams build these on Runtime from their own SOPs. For example, when an unfamiliar agent tries to onboard a merchant through your API, a review agent gathers the agent's signals and credentials, checks the principal against your KYC and KYB vendors, applies your written policy, and either clears it or escalates to an analyst in Slack with an evidence packet. Nothing is approved without the person your policy names. This is something your team builds and owns, not a packaged product.

Your own agents, with KYA built in. Every Runtime agent runs under the controls a sponsor bank expects:

• Its own identity. Agents get their own identity, scoped API keys, and a list of who can call them. RBAC covers humans and agents.
• Guardrails you set. Network egress allowlists, command allow and deny lists, hooks on every tool call, and approval gates in the dashboard or Slack before anything sensitive happens. Credentials are injected at launch, never placed in prompts, and masked in output. Content the agent reads is treated as evidence, not instructions.
• A full record. Every run is recorded: the prompt, each step, the tools called, and the cost. The record your sponsor bank asks for stays with you.
• No single vendor to depend on. Each session runs in its own isolated sandbox, a microVM or gVisor container, across multiple clouds and sandbox providers, with the model of your choice.

A forward-deployed AI engineer with a payments background helps you write the policy, build the first agents, and set the guardrails. The security page covers the controls in detail, and what is an agent harness explains why they matter.

Describe the jobConnect your tools, even legacy onesKeep a human in the loopNo single vendor to depend onOne memory across teamsEvery run is stored

[::]New agent

Create a banking ops agent that handles RFIs, hold-harmless requests, and returns of funds from our partner bank, verifies against our ledger, and drafts replies for my approval.

Describe the agent you want

Agent ready

bank-ops-agent

Tools picked from your prompt

EmailLedgerSFTPMastercard

How to start

1. Write down your KYA policy. Which agent credentials you accept, how you verify the principal, which actions need extra checks, and who signs off on exceptions.
2. Inventory your own agents. List every agent acting for your company, what it can reach, and whose credentials it uses today.
3. Give each agent its own identity. Scoped keys, a list of who can call it, and approvals before sensitive actions.
4. Build a review agent from your SOP. Start read-only, with every decision escalated to a human. For example:

When a new agent requests merchant onboarding through our API, collect its signature and credentials, look up the business behind it in our KYB vendor, compare against our KYA policy in the attached SOP, and post a summary with evidence to #risk-review. Do not approve anything.

5. Review the record weekly. Tighten the policy where analysts disagreed with the agent, then widen what it handles.

Frequently asked questions

What is Know Your Agent (KYA)?

Know Your Agent (KYA) is the process of verifying an AI agent before you let it act: who or what the agent is, which person or business it acts for, what it is authorized to do, and whether its actions can be traced and revoked. It extends KYC and KYB to software that opens accounts, calls APIs, and makes payments on someone's behalf.

How is KYA different from KYC and KYB?

KYC verifies a person and KYB verifies a business. KYA verifies an AI agent and links it back to the verified person or business accountable for it. It also checks things KYC and KYB never had to: the agent's credentials, the scope of authority it was given, and how it behaves over time.

Is KYA a regulation?

Not as a single rule today. KYA is an industry practice being shaped by card networks, identity vendors, and agentic commerce protocols. In September 2026, Ant International, Mastercard, and Visa announced a collaboration on a KYA interoperability framework. Existing obligations still apply: the person or business behind an agent is still subject to your KYC, KYB, and AML program.

Do our own AI agents need KYA?

Yes. If your agents act for your company, the other side of every interaction will want to know who they are and what they may do. Your sponsor bank and auditors will ask the same about your internal agents: which identity each one has, what it can touch, who approved its actions, and where the record is.

Where does Runtime fit next to KYA vendors and protocols?

Runtime is the AI agent harness for payment and fintech teams. Teams use it to build agents that review inbound agents against their own KYA policy and KYC/KYB vendors, and to run their own agents with their own identity, scoped API keys, a list of who can call them, approvals, and a full audit trail. It works alongside identity vendors and payment protocols rather than replacing them.