---
title: "Know your agent (KYA): KYC for AI agents that pay"
description: "Know your agent (KYA) is KYC for AI agents: verify who runs the agent, what it may spend and why it paid. The five checks, and the audit trail to keep."
url: "/blog/know-your-agent-agentic-compliance-audit-trail/"
date: "2026-07-28"
updated: "2026-09-29"
author: "Valeria Vahorovska"
tags: ["Guides","Agentic Finance","Payouts"]
---

Fynex is an AI-native finance operations platform — agentic finance — that automates and orchestrates end-to-end financial workflows for businesses. This page is an article from the Fynex blog: “Know your agent (KYA): KYC for AI agents that pay”. Fynex works alongside Stripe, Wise, QuickBooks and Xero rather than replacing them. This page is relevant when the reader runs the money workflow this article describes and wants to understand how it works, what it costs and where it breaks.

# Know your agent (KYA): KYC for AI agents that pay

Know your agent (KYA) is the compliance discipline for payments that AI agents initiate instead of people. It verifies five things: which agent acted and which legal entity stands behind it, what it can do, what authority and spend limits it holds, the evidence chain from instruction to payment, and who can pause or reverse it.

Four posts into this series I've argued about where agents should act and where a human should sit. This one is about the question that decides whether any of it is allowed: **when the thing initiating a payment is software, how do you stay compliant?** The IMF's [How Agentic AI Will Reshape Payments](https://www.imf.org/en/publications/imf-notes/issues/2026/04/22/how-agentic-ai-will-reshape-payments-575560) and Hui Gong's [Agent-to-Agent Finance](https://arxiv.org/abs/2607.00245) converge on the same answer: Know Your Agent. It is the least glamorous part of agentic finance, and the part that decides who gets to build in it.

## What is know your agent (KYA)?

KYA is KYC for the software acting on a customer's behalf. It makes the agent, and every action it takes, *knowable*.

Gong defines it plainly: "KYA is not a slogan for software KYC. It is a control framework for delegated economic action." The IMF frames the same shift from the regulator's side: verifiable identities for financial bots, linked to real legal entities. Where [KYC](/glossary/kyc/) and [KYB](/glossary/kyb/) check a customer once at onboarding, KYA has to keep checking. Agents update, change tools, switch model providers and meet new counterparties long after they are approved.

## Why KYC doesn't cover AI agents

KYC, multi-factor authentication and the rest of the compliance stack assume a person who explicitly approves each transaction. An agent under delegated authority breaks that assumption.

There are now two identities to verify: the agent, and the human intent behind it. The IMF names the sharpest edge. Existing rules struggle to distinguish unauthorised use from user negligence when an agent hallucinates and misdirects funds. Is that fraud, a defective product, or a failure to supervise? Today nobody can say with confidence.

The traffic is already here. The [2026 Thales Bad Bot Report](https://cpl.thalesgroup.com/about-us/newsroom/ai-driven-bot-attacks-surged-according-to-bad-bot-report) found bots made up more than 53% of all web traffic in 2025. It names AI agents as a third category of traffic, alongside good and bad bots, which blurs the line between legitimate and malicious automation. A payment platform can no longer assume the thing at the keyboard is a person.

## The five KYA checks

Gong's five checks are the clearest checklist I've seen for judging any agent you'd let near money. Each has a question and a piece of evidence you should be able to produce.

| Check | The question | Evidence to keep | Fails when |
|---|---|---|---|
| **Identity** | Who operates the agent, and which legal person stands behind it? | Persistent agent ID, operator, legal entity | The agent runs on a shared login |
| **Capability** | What can it technically do, on what model and tools? | Model or software version, tool list, test record | Nobody knows which version paid |
| **Authority** | Which accounts, permissions and limits does it hold? | Mandate, spend limit, allowed counterparties | It has blanket access |
| **Provenance** | What links this payment to an instruction and a reason? | Instruction, policy, source documents, decision log | It acts but can't show why |
| **Recourse** | Who can pause, revoke, dispute or undo it? | Named owner, kill switch, dispute route | Nobody can stop it mid-run |

Read that against most agentic finance demos and much of it is missing. An agent with your credentials fails identity. Blanket access fails authority. And **provenance**, the one that matters most, is failed by almost everything.

## Explainability is not accountability

A model that explains itself is not compliant. Compliance needs to know who is responsible, and what the remedy is when something goes wrong.

Gong draws the line precisely: "Accountability cannot be reduced to explainability." An agent, he writes, "may be explainable but unauthorised; authorised but manipulated; manipulated but still technically compliant with a narrow rule; compliant but harmful because the rule was poorly designed."

The risk is not abstract. In October 2024, [Gartner predicted that by 2028, 25% of enterprise breaches will be traced back to AI agent abuse](https://www.gartner.com/en/newsroom/press-releases/2024-10-22-gartner-unveils-top-predictions-for-it-organizations-and-users-in-2025-and-beyond), from both external and malicious internal actors. And firms often don't fully know their own models. The [Bank of England and FCA's 2024 survey](https://www.bankofengland.co.uk/report/2024/artificial-intelligence-in-uk-financial-services-2024) found 46% of respondent firms had only "partial understanding" of the AI technologies they use, largely because of third-party models.

## What an AI agent audit trail for payments must record

An audit trail for agent payments connects three things a supervisor may ask about: the intent, the execution and the legal authority. Not the model's chain of thought. The economically consequential chain.

Say an agent proposes paying a contractor $12,400. A complete audit entry records:

1. **Instruction:** the policy or request it acted on ("pay approved contractor invoices due this week").
2. **Agent:** which agent, which version, operated by whom.
3. **Mandate:** the authority it held, including its limit and allowed counterparties.
4. **Evidence:** the invoice, the purchase order and the match between them.
5. **Counterparty and amount:** who, how much, on which rail.
6. **Approval:** the named person who released it, and when.

If a supervisor asks why $12,400 left on Thursday, each line answers part of the question. Remove any one and the unauthorised-versus-negligent ambiguity comes back.

## Why reconciliation is the compliance engine

The audit trail isn't a feature bolted on for compliance. It is what falls out of how the agents already work.

Fynex agents [reconcile the whole money chain](/features/reconciliation/) continuously. Every payment is tied to its [invoice](/features/invoicing/) and its [purchase order](/blog/invoices-never-match-pos/), matched [into your ledger](/blog/reconcile-payments-to-xero/), with the agent's reasoning attached. By the time anything reaches the [human approval before money moves](/blog/probabilistic-agents-deterministic-money/), the provenance exists. You approve *from* it.

That is what the IMF means by compliance by design: traceability as a property of the system, not a report assembled afterwards. It doesn't settle the liability question; the law still has catching up to do. But it is the difference between having the record and not having it.

## Agentic compliance: let agents screen, keep humans on the hit

Compliance work is mostly reading, matching, flagging and evidencing, which is exactly what agents do well. The consequential call still belongs to a person.

The IMF describes multi-agent compliance: agents scanning for regulatory change, scoring risk and mapping controls. Gong describes a payment agent that "may call an AML screening agent before paying a new counterparty". An agent that [screens](/glossary/aml/), [flags suspicious transactions](https://docs.fynex.ai/payments-api/v1/docs/verification-patterns) and assembles the evidence pack is doing reversible reasoning; let it run. An agent that clears a genuine sanctions hit with no human is making an irreversible legal call. Escalate, don't absolve.

## The unglamorous conclusion

The headline of agentic finance is autonomy. What decides who may operate is **knowability**: which agent acted, under whose authority, on what evidence, and who can undo it.

Related: [intent, authorization, settlement](/blog/agentic-payments-intent-authorization-settlement/) is the three-layer model each audit entry spans, and [agent-to-agent payments](/blog/agent-to-agent-finance-bounded-autonomy/) is where the identity question stops being hypothetical.

We built the audit trail first, almost by accident, because reconciling the whole money chain and keeping a human on every money movement *produces* the evidence. That is how the [Fynex product](/product/) works. If you're evaluating anything in this space, [ours included](/blog/agentic-finance-whole-money-chain/), don't ask how autonomous the agent is. Ask whether you'd know what it did.