Post your first agent-attributed transaction
If you want to try this yourself, clone the Formance Ledger on GitHub, run it locally, and post your first agent-attributed transaction.
An AI procurement agent settles a $250,000 supplier invoice. The framework times out, retries, and posts the charge twice. Your ledger records both movements but cannot name the agent, the mandate, or the budget behind either one. This happens when payment systems can't identify the agent behind a request.
AI agents are starting to initiate payments on behalf of legal entities, and payment systems now have to answer a new question at authorization time: which agent, acting under whose authority, is requesting this movement of funds?
Merchants, fintechs, and any team accepting agent-initiated traffic see this problem first, because the ledger has to name the actor when a dispute lands.
Know Your Agent (KYA) is the set of identity, authentication, and mandate-scope controls a payments system runs on an AI agent before accepting a transaction request.
This guide covers how KYA works, the agent registries card networks run, and how KYA evidence should flow into your transaction records.
Know Your Agent (KYA) combines checks on an AI agent's identity, authentication, and scope of authority with transaction-level audit evidence before accepting a request.
Identity confirms which agent is making the request, while authentication proves this request genuinely came from that agent and not an impersonator using its credentials. Scope finalizes what the agent is authorized to do.
It differs from Know Your Customer (KYC) in timing. KYC verifies a human once at onboarding, while KYA repeats identity and authority checks during operation because an agent can be compromised or repurposed after initial verification.
Three primitives make KYA operational:
Agent registration issues each agent a verifiable identity tied to a principal (the legal entity operating the agent) and a declared scope of authority.
Verifiable identities for financial bots should be linked to legal entities, so every agent credential resolves to someone who can be held accountable.
Without the legal-entity binding, an incident review has no name to attach to a movement, and dispute resolution has no counterparty to pursue.
Cryptographic signatures are per-request proofs, generated with the agent's private key, that a given Hypertext Transfer Protocol (HTTP) request came from the registered agent.
Two IETF drafts define the mechanics: Web Bot Auth and hosted key directories. Agents that can't host a stable HTTPS origin for their keys can look the same as abusive automation. Both drafts are still works in progress, so the details could still change.
Signing every request (not only the session opener) closes the mid-session compromise issue. An onboarding-only check trusts the entire session to a credential that may have been revoked, suspended, or exfiltrated after the first request cleared.
Per-request verification also enforces a fail-closed default, such as a signature that cannot be validated against the agent's published key material never reaches the ledger.
Network tokens bound to registered agent identities give merchants and acquirers a way to distinguish authorized agent transactions from generic automation traffic at authorization time. The token is an authorization-time identity signal, and local controls enforce posting-time budgets.
Authorization decisions and posting decisions run on different timelines and different data. The card network sees the token and the signed message, while the ledger sees the balance, the mandate metadata, and the accumulated postings for the current mandate period.
Neither the network nor the ledger can enforce the other's invariants, so each must enforce its own.
Card networks run the operational registries for agent identity by issuing verifiable agent identities, validating request signatures, and binding registered agent identities to network tokens carried through the authorization path.
Visa's Trusted Agent Protocol and Mastercard's Agent Pay are the two infrastructures teams will validate against. Beyond the card networks, agent-native protocols each carry their own identity conventions, while banking and open-banking rails carry none, leaving the ledger as the only place agent identity is recorded.
Visa launched the Trusted Agent Protocol (TAP) in October 2025 as part of Visa Intelligent Commerce.
Agents sign HTTP requests using RFC 9421 HTTP Message Signatures, built on the emerging Web Bot Auth standard.
The Signature-Agent header points to the operator's published key directory, Signature-Input declares the signed request components, key ID, algorithm (Ed25519), and validity window, and Signature carries the signature itself.
The merchant integration fetches the agent's public key material at authorization time, validates the signature against the signed message components, and decides how to behave when the key fetch fails or the signature does not verify.
Mastercard is rolling out Agent Pay. The Agentic Token is bound to the cardholder's registered agent and spend policy, so it only works within the merchant categories, spend ceiling, and expiration the cardholder set.
Verifiable Intent, Mastercard's companion framework built with Google, is the evidence layer. It records what the user authorized so issuers and merchants can use it for dispute resolution. It interoperates with AP2 and Universal Commerce Protocol.
The token is an authorization-time identity and policy signal. It is not a live mandate, so it cannot be used outside the policy it was minted against. The mandate enforcement at posting time still runs separately in the ledger.
Formance Ledger's flexible metadata model supports attribution fields that can expand as new agent protocols emerge, without migrations.
Non-card rails have no equivalent to the card networks' agent registries yet. Agent Payments Protocol (AP2), Model Context Protocol (MCP), and the Agent Commerce Protocol (ACP) each define their own agent-identity, mandate, and signature conventions, and no field-level mapping exists between them.
Infrastructure teams accepting agent traffic on more than one protocol should treat protocol-specific identity as an authorization-time signal. Keep the ledger-side evidence model protocol-agnostic, so adding a second protocol is a metadata change.
Banking-rail and open-banking connectors carry no agent identity. An ACH transfer or a wire authenticates the account holder, and not the AI agent acting on the account holder's behalf.
When an agent initiates a payment through a bank API or an open-banking aggregator (Plaid, Tink, or Powens), the identity binding has to be established and recorded upstream, in the ledger and the mandate metadata, before the request leaves the merchant's infrastructure.
The bank rail sees a legitimate account holder, while the ledger is the only layer that can name which agent moved the funds and under which mandate.
KYA evidence flows into transaction records through a dedicated budget account per agent, mandate metadata that attributes every posting, atomic mandate enforcement, and the capture of the five artifacts a dispute will demand.
Give each agent its own budget account that holds the mandate's spending limit. Instead of scattering spend checks across your application code, this pattern puts a single rule in the ledger: an agent cannot spend more than its budget account balance.
Because the balance check happens inside the ledger itself, it works correctly even when many requests arrive at once, and even when the same request is retried.
Give each mandate period its own sub-account under the agent. Open a new account for the next quarter instead of editing a live balance to reset a quarterly limit. Keep the prior quarter's postings attached to the account that authorized them.
Tag every posting with the agent and the mandate that authorized it, and keep those postings in an immutable transaction log.
Attach a mandate reference (a mandate ID plus a hash of the signed mandate) to every transaction, so each posting shows who acted and under what authority. The hash makes the reference verifiable, so a reviewer can hash the mandate document shown in a dispute and confirm it matches the mandate the posting ran under.
Keep the principal's identifier on the agent account's metadata instead of repeating it on every posting.
Set up your transactions to reject any posting without a mandate reference. An untagged movement cannot enter the ledger.
Atomic enforcement means the posting and the budget check either both succeed or both fail in a single transaction. There should be no half-finished state and no gap between checking the balance and writing the posting.
Formance Ledger stores the immutable, hash-chained log, and Numscript, Formance's language for describing financial transactions, expresses the mandate as logic that both engineering and finance teams can read.
In the example below, procurement-07 operates under a signed mandate with a quarterly budget and pays a $250,000 supplier invoice.
@agents:procurement_07:budget holds the agent's funded budget, and @suppliers:acme:payable holds the amount owed to the supplier.
// SUPPLIER_INVOICE_SETTLEMENT
// Event: procurement agent 07 settles a $250,000 supplier invoice
send [USD/2 25000000] (
source = @agents:procurement_07:budget
destination = @suppliers:acme:payable
)
set_tx_meta("event_type", "supplier_invoice_settlement")
set_tx_meta("invoice_id", "inv001")
set_tx_meta("agent_id", "procurement-07")
set_tx_meta("mandate_id", "mnd001")
If @agents:procurement_07:budget holds less than $250,000, the whole transaction fails. The ledger records the movement of value, while the actual money transfer to the supplier runs through a connected payment service provider (PSP) or bank. The ledger posting and the real-world payment stay in sync through the shared metadata.
Tagging postings with the mandate makes funds traceability work. You can trace back from the supplier payout to the mandate that authorized it.
The same one-account-per-agent pattern works when AI agents move money, including spending caps, merchant category limits, and time-limited permissions.
For any agent-initiated transaction, capture five things on demand: the agent's identity, the company or entity the agent works for, the mandate reference and its scope, a stable request ID built from the tool-call arguments, and the resulting postings in your system of record.
The stable request ID matters because agent frameworks often retry tool calls as brand-new requests, sometimes with slightly different wording. A session-based idempotency key does not survive that kind of retry.
Building the request ID from the tool-call arguments ties deduplication to what the agent meant to do. If getting any of these five pieces means digging through application logs, the layer that holds the money lacks the regulatory-grade audit-trail traceability needed to survive a dispute.
Bringing KYA into your ledger means every agent-initiated posting answers who acted, under what authority, and against which budget, before a dispute forces the question. That means budget accounts that enforce the mandate ceiling, metadata on each posting, and an immutable transaction log.
KYA needs three things working together: a registered agent identity, a signed request proving that identity at runtime, and a transaction record naming the agent, the principal, and the authorizing mandate.
Card networks are building the identity and signature layers. The transaction record, the layer that actually tracks which agent moved which funds under which mandate, sits with whoever owns the ledger. Without it, the other two layers have nowhere durable to land.