By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

Who KYCs the Agent?

Lana Schwartzman
October 5, 2026
Schwartzman boasts 19 years of experience in fintech and digital assets compliance, with a strong history of designing compliance programs and leading licensure strategies in crypto and financial companies.
Summary

I’ve now spent over 20 years in AML, and the first question I keep getting is: Who decided to send this money?

Last week at Sibos in Miami, Fed Governor Christopher Waller asked the same question to a room full of bankers:

"Who is on the hook if an agent makes the wrong purchase?"

I haven't stopped thinking about his question since.

Funny enough, at a client dinner the same night, the table's verdict on Sibos was pretty blunt in that every panel sounded the same. The ongoing keywords of payments, tokenization, stablecoins, AI, and repeat. Buried in all the sameness was the question I think matters most for anyone in compliance.

Gov. Waller split agentic commerce into two models: Agent-assisted, where you stay in control and agent-delegated, where the buyer "grants authority to an AI agent to shop and make payments on their behalf." He expects consumer shopping to go first and B2B to follow, and he named the catch himself: "higher transaction values typical in B2B commerce amplify the financial exposure from agent errors."

In other words, for my compliance colleagues: larger transaction values, accelerated decision-making, and zero manual sign-off.

And the Sibos program already had the next step on the agenda. One session in the Securities and FX stream is called "AI as market agent and counterparty." The keyword here is “counterparty.” We're not talking about a chatbot helping someone fill out a form anymore.

Call it Know Your Agent (KYA), the agent-era version of KYC: who the agent acts for, what the agent is allowed to do, and how you shut it off.

We already know how to do this. Sort of.

Banks have handled "someone acting for someone else" for a long time. When a company wires $5 million, nobody checks only the company. You check the signatory list, the board resolution, the limit on each signer, the power of attorney, any standing instructions, etc. Authority has a paper trail, and every ops team knows where the paper lives.

The problem is the paper. An agent needs the same trail, in a format a machine reads before the payment moves, and one the counterparty on the other side sees too.

Six know your agent (KYA) questions for compliance teams

Six questions I'd put to any compliance team rolling out (or receiving) agent payments:

Who is the principal? Our CDD covers the person or the business. The agent's mandate sits outside the file.

What is the agent allowed to do? Limits, payees, assets, jurisdictions, an end date. Where do those rules live? Does the other side ever see them? And when both sides run agents, whose rules win?

Whose instruction is this? FATF's revised Recommendation 16 says the payment chain starts "with the financial institution which receives an instruction from the customer." Okay. A human sets a goal. The agent picks the payee, the amount, the timing and the rail. Which part was the instruction?

Who owns the sanctions hit? OFAC's own Sanctions Compliance Guidance for the Virtual Currency Industry (October 2021) spells out the rule: civil penalties apply on "a strict liability legal standard." Liability attaches even without knowledge or intent. "The agent picked the payee" won't save you. The decision moved to software. The liability didn't.

What will the agent learn to game? This one worries me most. Tell an agent to minimize fees and friction, and the agent figures out payments under the $3,000 U.S. Travel Rule threshold move with less data. So ten payments of $2,900 instead of one of $29,000. If a human did this, we'd be opening a case. When an agent does this, the vendor calls the behavior optimization.

How do you take the authority back? Think about removing an authorized signer. The company sends a letter, the bank updates the signatory list, and the old signer is out. Now picture one agent connected to a company's bank account, corporate card and exchange account at the same time. The company drops the vendor. Who tells all three? If one of them misses the update, the old agent still holds working credentials, and the next payment goes out anyway. Granting authority to an agent takes one click. Taking the authority back has to be as fast, everywhere at once.

The part banks should worry about

Today, a business logs into the bank to pay a supplier. The bank sees the customer, the payment and the approval. The relationship lives at the bank.

With an agent, the business never logs in. The agent finds the supplier, agrees the price and sends the payment from whichever account is connected. The customer talks to the agent, not the bank. The bank still holds the money and still carries the regulatory risk, but loses the relationship.

So what keeps the bank relevant? Control. The bank sits in the right spot to check the agent's authority before money leaves the account:

  • Is this agent allowed to make this payment?
  • Is the amount inside the limits the customer set?
  • Has the customer pulled the agent's authority?
  • Is there a record of what the customer asked for and what the agent did?
  • If the agent gets the payment wrong, who fixes the problem for the customer?

Compliance teams already do this kind of checking every day. With agents, those checks stop being back-office work. They become the reason customers keep banking with you.

Where the Travel Rule fits (and where the Travel Rule stops)

The Travel Rule already does half the job for virtual asset transfers. Originator and beneficiary data move with the transfer between the VASPs on each side. What the data doesn't carry yet is the mandate: who authorized the agent, for what, within which limits, and until when.

Look at IVMS101, the common data model for Travel Rule messages. There's an originator, a beneficiary, the VASPs on each side and any intermediary VASPs. There's no field for software acting on someone's behalf.

Timing matters too. On a blockchain or a shared ledger with final settlement, there's no recall. If an agent pays the wrong party at 2 a.m. on a Saturday, the money is gone before anyone wakes up. The check has to happen before settlement, not after.

And standards take a long time. The FSB's Martin Moloney noted in July ISO 20022 adoption sits around 77% of fast payment systems and 53% of settlement systems, more than two decades in. Agents won't wait twenty years for us.

This is why we built the Transaction Authorization Protocol (TAP) as an open protocol. Agents acting for each party exchange identity, authorization and settlement details before anything settles. A connect message (TAIP-15) carries the mandate itself: the principal, the agent asking for authority, allowed purposes, spending limits, approved beneficiaries and assets, and an expiry. The other side sees the authority before the money moves and not after.

At Notabene we talk about two problems: knowing who sits behind a blockchain address, and settling a payment with counterparties you know. Agents add a twist to the first one. Knowing who sits behind the address now includes knowing who speaks for them.

Even Waller pointed this way, toward standards showing what the buyer intended and how the agent carried out the instruction.

If I were back in a CCO seat

The things I'd start thinking about when it comes to an “AI Payment Agent Compliance Program” would be:

  1. Find the agents you already have. Ask where software, not a person, starts payments today. Look at treasury tools, invoice platforms and vendor apps, including the ones nobody calls "AI."
  2. Write down what each agent is allowed to do. Record who gave the permission, what the agent is allowed to pay for, the spending limits and the end date. Keep this in the customer file, next to the KYC.
  3. Get the same details from the other side. Before a payment settles, ask the bank or VASP on the other end which agent sent the payment and who authorized the agent. The Travel Rule and pre-transaction authorization would be a key mitigating control here. I would also spell out in your contracts who pays when an agent makes a mistake.
  4. Save the request and the result. Keep a record of what the customer asked for and what the agent did. When a dispute comes in, the answer sits in the difference between the two.
  5. Practice shutting an agent off. Turn off one agent's access and time how long until the payments stop. If the answer is hours, you have a gap to fix.

KYC tells us who the customer is. Know Your Agent has to tell us who speaks for the customer, how far the authority goes, and how to take the authority back.

If you're already seeing agent-initiated payments in production, I'd like to compare notes.

References

FAQs

What is Know Your Agent (KYA)?

Know Your Agent (KYA) is the agent-era extension of KYC. KYC verifies who the customer is. KYA verifies who an AI agent acts for, what the agent is authorized to do (limits, payees, assets, jurisdictions, an end date), and how that authority gets taken back.

How is KYA different from KYC?

KYC covers the person or the business. An agent's mandate sits outside that file. KYA adds the authority layer: the principal behind the agent, the scope of the agent's permissions, and a record of what the customer asked for versus what the agent did.

Does the Travel Rule cover payments started by AI agents?

Partly. For virtual asset transfers, originator and beneficiary data still move between the VASPs on each side. But IVMS101, the common data model for Travel Rule messages, has no field for software acting on someone's behalf, so the agent's mandate doesn't travel with the payment today.

Who is liable when an AI agent makes a sanctioned payment?

The institution. OFAC applies civil penalties on a strict liability standard, so liability attaches even without knowledge or intent. "The agent picked the payee" won't save you. The decision moved to software. The liability didn't.

How do you revoke an AI agent's payment authority?

The same way you remove an authorized signer, except everywhere at once. If one agent is connected to a company's bank account, corporate card and exchange account, every one of them has to cut off access. Test it: turn off one agent's access and time how long until the payments stop.

What should an agentic payments compliance program include?

Five starting points: find the agents already initiating payments, write down what each one is allowed to do, get the same details from the counterparty before settlement, save the request and the result, and practice shutting an agent off.

Who KYCs the Agent?

Insights

I’ve now spent over 20 years in AML, and the first question I keep getting is: Who decided to send this money?

Last week at Sibos in Miami, Fed Governor Christopher Waller asked the same question to a room full of bankers:

"Who is on the hook if an agent makes the wrong purchase?"

I haven't stopped thinking about his question since.

Funny enough, at a client dinner the same night, the table's verdict on Sibos was pretty blunt in that every panel sounded the same. The ongoing keywords of payments, tokenization, stablecoins, AI, and repeat. Buried in all the sameness was the question I think matters most for anyone in compliance.

Gov. Waller split agentic commerce into two models: Agent-assisted, where you stay in control and agent-delegated, where the buyer "grants authority to an AI agent to shop and make payments on their behalf." He expects consumer shopping to go first and B2B to follow, and he named the catch himself: "higher transaction values typical in B2B commerce amplify the financial exposure from agent errors."

In other words, for my compliance colleagues: larger transaction values, accelerated decision-making, and zero manual sign-off.

And the Sibos program already had the next step on the agenda. One session in the Securities and FX stream is called "AI as market agent and counterparty." The keyword here is “counterparty.” We're not talking about a chatbot helping someone fill out a form anymore.

Call it Know Your Agent (KYA), the agent-era version of KYC: who the agent acts for, what the agent is allowed to do, and how you shut it off.

We already know how to do this. Sort of.

Banks have handled "someone acting for someone else" for a long time. When a company wires $5 million, nobody checks only the company. You check the signatory list, the board resolution, the limit on each signer, the power of attorney, any standing instructions, etc. Authority has a paper trail, and every ops team knows where the paper lives.

The problem is the paper. An agent needs the same trail, in a format a machine reads before the payment moves, and one the counterparty on the other side sees too.

Six know your agent (KYA) questions for compliance teams

Six questions I'd put to any compliance team rolling out (or receiving) agent payments:

Who is the principal? Our CDD covers the person or the business. The agent's mandate sits outside the file.

What is the agent allowed to do? Limits, payees, assets, jurisdictions, an end date. Where do those rules live? Does the other side ever see them? And when both sides run agents, whose rules win?

Whose instruction is this? FATF's revised Recommendation 16 says the payment chain starts "with the financial institution which receives an instruction from the customer." Okay. A human sets a goal. The agent picks the payee, the amount, the timing and the rail. Which part was the instruction?

Who owns the sanctions hit? OFAC's own Sanctions Compliance Guidance for the Virtual Currency Industry (October 2021) spells out the rule: civil penalties apply on "a strict liability legal standard." Liability attaches even without knowledge or intent. "The agent picked the payee" won't save you. The decision moved to software. The liability didn't.

What will the agent learn to game? This one worries me most. Tell an agent to minimize fees and friction, and the agent figures out payments under the $3,000 U.S. Travel Rule threshold move with less data. So ten payments of $2,900 instead of one of $29,000. If a human did this, we'd be opening a case. When an agent does this, the vendor calls the behavior optimization.

How do you take the authority back? Think about removing an authorized signer. The company sends a letter, the bank updates the signatory list, and the old signer is out. Now picture one agent connected to a company's bank account, corporate card and exchange account at the same time. The company drops the vendor. Who tells all three? If one of them misses the update, the old agent still holds working credentials, and the next payment goes out anyway. Granting authority to an agent takes one click. Taking the authority back has to be as fast, everywhere at once.

The part banks should worry about

Today, a business logs into the bank to pay a supplier. The bank sees the customer, the payment and the approval. The relationship lives at the bank.

With an agent, the business never logs in. The agent finds the supplier, agrees the price and sends the payment from whichever account is connected. The customer talks to the agent, not the bank. The bank still holds the money and still carries the regulatory risk, but loses the relationship.

So what keeps the bank relevant? Control. The bank sits in the right spot to check the agent's authority before money leaves the account:

  • Is this agent allowed to make this payment?
  • Is the amount inside the limits the customer set?
  • Has the customer pulled the agent's authority?
  • Is there a record of what the customer asked for and what the agent did?
  • If the agent gets the payment wrong, who fixes the problem for the customer?

Compliance teams already do this kind of checking every day. With agents, those checks stop being back-office work. They become the reason customers keep banking with you.

Where the Travel Rule fits (and where the Travel Rule stops)

The Travel Rule already does half the job for virtual asset transfers. Originator and beneficiary data move with the transfer between the VASPs on each side. What the data doesn't carry yet is the mandate: who authorized the agent, for what, within which limits, and until when.

Look at IVMS101, the common data model for Travel Rule messages. There's an originator, a beneficiary, the VASPs on each side and any intermediary VASPs. There's no field for software acting on someone's behalf.

Timing matters too. On a blockchain or a shared ledger with final settlement, there's no recall. If an agent pays the wrong party at 2 a.m. on a Saturday, the money is gone before anyone wakes up. The check has to happen before settlement, not after.

And standards take a long time. The FSB's Martin Moloney noted in July ISO 20022 adoption sits around 77% of fast payment systems and 53% of settlement systems, more than two decades in. Agents won't wait twenty years for us.

This is why we built the Transaction Authorization Protocol (TAP) as an open protocol. Agents acting for each party exchange identity, authorization and settlement details before anything settles. A connect message (TAIP-15) carries the mandate itself: the principal, the agent asking for authority, allowed purposes, spending limits, approved beneficiaries and assets, and an expiry. The other side sees the authority before the money moves and not after.

At Notabene we talk about two problems: knowing who sits behind a blockchain address, and settling a payment with counterparties you know. Agents add a twist to the first one. Knowing who sits behind the address now includes knowing who speaks for them.

Even Waller pointed this way, toward standards showing what the buyer intended and how the agent carried out the instruction.

If I were back in a CCO seat

The things I'd start thinking about when it comes to an “AI Payment Agent Compliance Program” would be:

  1. Find the agents you already have. Ask where software, not a person, starts payments today. Look at treasury tools, invoice platforms and vendor apps, including the ones nobody calls "AI."
  2. Write down what each agent is allowed to do. Record who gave the permission, what the agent is allowed to pay for, the spending limits and the end date. Keep this in the customer file, next to the KYC.
  3. Get the same details from the other side. Before a payment settles, ask the bank or VASP on the other end which agent sent the payment and who authorized the agent. The Travel Rule and pre-transaction authorization would be a key mitigating control here. I would also spell out in your contracts who pays when an agent makes a mistake.
  4. Save the request and the result. Keep a record of what the customer asked for and what the agent did. When a dispute comes in, the answer sits in the difference between the two.
  5. Practice shutting an agent off. Turn off one agent's access and time how long until the payments stop. If the answer is hours, you have a gap to fix.

KYC tells us who the customer is. Know Your Agent has to tell us who speaks for the customer, how far the authority goes, and how to take the authority back.

If you're already seeing agent-initiated payments in production, I'd like to compare notes.

Notabene is the trust layer for global crypto money movement.

Notabene Flow — the first open stablecoin payments platform for businesses—and Notabene Transact—the world's largest Travel Rule-compliant transaction authorization platform for regulated institutions—are built on the Transaction Authorization Protocol (TAP), an open messaging standard that enables verified entities to transact securely.

The Notabene Network connects thousands of trusted counterparties, facilitating over $1T in transaction volume annually across over 100 jurisdictions.