Agentic payments · Risk

An audit trail for AI agent payments. Who authorised what, and who is liable.

What risk and compliance teams need before an AI agent pays: know your agent, the evidence behind every decision, liability questions, and the audit packet.

By Sanjay Singh, Founder · Last updated: 29 September 2026

Get the agent audit checklist

On this page 14 sections

The short answer

An audit trail for AI agent payments lets anyone pick a payment and trace it back to the agent that proposed it, the authority it acted under, the rule that allowed it, the person who approved it and the evidence that it settled. Without that trail, nobody can answer the question every agent payment eventually raises: who authorised this, and who is responsible now?

Liability depends on the rail, the contract and the law that applies, and it is never settled by the model. It is settled by evidence. The trail is that evidence.

Know your agent

Card networks have started to require that agents are identified before they pay. Mastercard says only registered agents can transact under Agent Pay, and describes the principle as know your agent. Visa’s Trusted Agent Protocol lets a merchant verify an agent from a signed request. Inside your own business the same principle applies:

Every agent has its own identity, never a shared user account or a person’s credentials.
Every agent has an owner: a named team and an accountable person.
Every agent has a version. When its model, prompt or tools change, the record shows which version made which payment.
Every agent has a mandate it cannot change, stating what it may pay, to whom, up to what limits and until when.

Who is liable when an agent pays?

There is no single answer, but the questions are predictable:

Was the payment authorised? In the UK, the Payment Services Regulations generally cap a payer’s liability for unauthorised transactions at £35, unless they acted fraudulently or with gross negligence. Whether an agent’s payment counts as authorised turns on how consent was given and recorded.
Which rail was it? Card payments carry dispute and chargeback rules. Bank push payments are usually final, and recovery depends on the receiving bank and on schemes such as the UK’s reimbursement requirement for authorised push payment scams.
What does the contract say? Between a business and its payment provider, and between a platform and the people it pays, the contract allocates much of the loss.
Did the controls work? If a payment broke the mandate, the question becomes why the system allowed it.

In every case, the party with the better record is in the stronger position. Nothing here is legal advice; take advice on your own flows.

The decision every payment needs on record

Mandate grantedWho granted it, scope, limits, expiry, version
Intent proposedAgent, version, task, payee, amount, key
Rule appliedAllowed, needs approval or refused, and why
Approved or refusedApprover and time, or the refusal
Executed and provenProvider reference, settlement, bank line

Refused and expired intents belong in the trail too: they are the proof that the mandate worked.

Each step should be an event that is appended and never edited. A correction is a new, explained event, so the trail shows what was known at each moment.

The audit packet

Most agent projects stall at the risk review, not at the technology. Reviewers want evidence they can check. Prepare this packet before you ask:

The agent register: each agent, its owner, its version history and what it can call.
The mandates: scope, caps, approvers, expiry and revocation, with every version kept.
Where the rules are enforced, and proof the agent cannot change them.
Failure behaviour: what happens when a check errors, times out, or the mandate has expired.
A decision sample: for a set of attempts, what the agent proposed, which rule decided, who approved.
Reconciliation: how each agent payment is matched to provider, settlement and bank evidence, and who owns a difference.
Liability and recovery: who bears the loss in each flow, and how disputes and recoveries work.

We turned this into a free agent audit checklist you can download as a CSV and work through with your risk team.

Tests an auditor will run

Trace forward: pick a mandate and list every payment made under it; check none breached it.
Trace back: pick a bank statement line and find the intent, the agent, the rule and the approver behind it.
Break a control: make the limit service unavailable and confirm no payment was sent.
Change a payee: alter a beneficiary’s bank details and confirm the next payment waited or needed approval.
Replay a timeout: confirm a retry queried status first and did not create a second payment.

How Flominzo records it

In Flominzo AgentPay, an agent submits a payment intent under a recorded mandate that states who granted it, what it may pay, to whom, up to what limits and until when. The deterministic payment core enforces it. Every tool call and decision is recorded as an event, with the agent as the actor. Raw provider files and callbacks are stored with their provenance before they are interpreted, and every financial decision keeps the evidence, the rule version and the person or rule that made it.

Agents never, on their own, move money, change limits or routing, close exceptions, or contact a provider or customer. Each payment is then reconciled against provider, settlement and bank evidence. See security and controls for the full list.

What each record must hold

Record	Fields to keep
Agent	Agent identifier, owner, version, the tools it can call, when it was created or changed
Mandate	Mandate identifier and version, who granted it and when, scope, payees, caps, approvers, start and expiry, revocation
Intent	Intent identifier, idempotency key, agent and version, task or request that led to it, payee, amount, currency, purpose, time
Decision	Allowed, needs approval or refused; the rule and its version; the reason in plain words
Approval	Approver, time, what they saw, and whether the approval arrived inside its window
Execution	Provider, provider reference, status history, retries and the lookups that resolved any unknown outcome
Evidence	Settlement file line, bank statement line, any return or reversal, and the closure decision

Retention and access

Keep the agent’s records for as long as your obligations require you to keep the payment records themselves; an agent payment is still a payment. Store raw provider files and callbacks with a hash and their source before anything interprets them, so the trail can be checked against what arrived, not just against what a system concluded. Give reviewers read access to the trail without giving anyone, least of all the agent, the ability to change it.

Common gaps in agent audit trails

Shared credentials. The agent pays through a person’s account, so the trail says the person did it.
Only successes are logged. Refused and expired intents vanish, and with them the proof that the controls worked.
Mandates are overwritten. The current limits are kept, the old ones are not, so past payments can’t be judged against the rules in force at the time.
The agent’s reasoning is the only record. A model’s explanation is kept, but not the rule and version that decided.
The trail stops at "sent". Nothing links the payment to the settlement file and the bank statement.

Who should own the trail

Not the team that builds the agent. The trail is evidence about the agent, so it should be owned by the function that answers for payments: finance operations or risk, with engineering making sure every event lands and nobody can edit it. Reviewing a sample of agent payments end to end each month is a small cost next to discovering a gap during an incident.

Questions

What is know your agent?

The principle that every agent is identified, owned and versioned before it can pay, so any payment can be traced to a specific agent and the person responsible for it.

How long should an agent payment trail be kept?

As long as your record-keeping obligations for payments require; the agent’s decisions should follow the same retention as the payments themselves.

Is a model’s explanation enough evidence?

No. An explanation helps a reviewer, but the evidence is the mandate version, the rule that decided, the approver and the provider and bank records.

Can an agent edit its own audit trail?

It must not. Events should be appended and never edited, and the agent should have no access to change its mandate or its history.

Sources

Let’s make it specific to you.

Bring your systems, payment flows, and questions. We’ll help define the next step.

Talk to the team