The payment can be wrong even when every system worked exactly as designed.
An AI agent reads an invoice, chooses a beneficiary, authorises a payment and sends the money. The rail settles correctly. The bank follows the instruction. The recipient exists.
Then someone discovers the agent paid the wrong account.
Who owns the loss?
What Matters
The IMF’s 2026 note on agentic payments proposes a useful three-layer model: intent, authorization and settlement. The distinction matters because an AI agent can misunderstand the first layer, hold legitimate authority at the second layer, and still trigger a perfectly final transaction at the third.
That is fundamentally different from a stolen card or hacked account. The transaction may be technically authorised and still be economically wrong.
The Signal
Payment networks are already building agent-specific identity and authorization layers. Visa’s Trusted Agent Protocol is designed to let merchants verify that an agent is legitimate and bind credentials to a particular merchant, purpose and time window. Mastercard’s Agent Pay similarly focuses on agent identity, verifiable intent and tokenized credentials.
Those controls solve an important problem: proving that a real principal allowed a legitimate agent to transact.
They do not automatically solve a second problem: did the agent choose the correct payee, amount and transaction?
The six places liability can break
1. Intent error
The user’s request is ambiguous, incomplete or misunderstood by the agent.
2. Beneficiary error
The agent selects the wrong recipient, wallet, merchant or bank account.
3. Authority error
The agent acts outside its spending mandate, approval limit or allowed purpose.
4. Execution error
The bank, processor, wallet or payment API executes an instruction incorrectly.
5. Settlement-finality problem
The rail makes the transfer irreversible before the mistake is discovered.
6. Recovery failure
The parties identify the error but cannot recall, freeze or recover the funds.
“Authorised” does not mean “correct”
This is likely to become one of the most important distinctions in agentic finance.
If a user grants an agent permission to pay approved invoices below $5,000, and the agent pays a fake invoice for $4,800 to the wrong supplier, the credential may have been valid. The agent may have stayed below its limit. The payment rail may have authenticated the transaction perfectly.
The failure happened before authorization: the agent classified the invoice or beneficiary incorrectly.
What NIST-style controls imply for agentic payments
NIST’s AI Risk Management Framework is not a payment-liability law, but its governance logic is directly relevant. AI risks should be governed, mapped, measured and managed across the lifecycle. NIST’s cybersecurity controls also emphasize access enforcement, event logging and auditable actions.
Applied to agentic payments, that means a defensible system should be able to reconstruct:
- what objective the agent was given;
- which data it relied on;
- which beneficiary it selected and why;
- what authority was in force;
- what checks passed before execution;
- which system submitted the payment;
- when settlement became final; and
- what recovery actions were attempted.
Without that chain, liability becomes a dispute about an invisible decision.
The DN Agent Payment Liability Map
| Failure | Most relevant actor | Key question | Likely control |
|---|---|---|---|
| Agent misunderstood user intent | Agent operator / deployer | Was the instruction sufficiently constrained? | Structured intent + confirmation threshold |
| Wrong beneficiary selected | Agent operator + payer | Was the payee independently verified? | Allowlist + beneficiary verification |
| Agent exceeded permission | Credential / authorization layer | Were limits technically enforced? | Hard spend and purpose limits |
| Bank sent wrong amount | Executing institution | Did execution match the submitted instruction? | Payment-system error controls |
| Correct instruction sent to scammer | Payer / agent / fraud controls | Was the scam detectable before settlement? | Fraud screening + step-up approval |
| Transfer cannot be reversed | Rail design | Was finality understood before sending? | Delay window / escrow / recall path |
Cards, bank transfers and crypto do not fail the same way
Card payments
Card systems have mature dispute and chargeback processes. Agentic credentials can potentially inherit many existing protections, though the question of delegated intent still matters.
Bank transfers
Recovery can depend heavily on payment type, jurisdiction and whether the transaction was unauthorised, erroneous or simply sent to a fraudster under valid credentials.
Stablecoins and crypto
On-chain settlement can become final quickly. If an agent sends to the wrong address, recovery may depend entirely on the recipient’s cooperation or an intermediary with freeze powers.
Escrowed agent payments
Escrow or conditional settlement can trade speed for recoverability, especially for high-value autonomous transactions.
DN Autonomous Payment Recovery Score
DN proposes a practical framework for measuring how dangerous an agent-initiated payment is before it is sent.
Beneficiary certainty — 25%
How strongly is the payee identity verified?
Authority precision — 20%
Are purpose, amount, merchant and time boundaries technically enforced?
Reversibility — 20%
Can the transfer be recalled, disputed or frozen?
Auditability — 15%
Can the full decision and authorization chain be reconstructed?
Fraud screening — 10%
Are anomalies and beneficiary risks checked before execution?
Human escalation — 10%
Do novel or high-risk payments trigger approval?
DN Payment Recovery Calculator
Score each factor from 0 to 100. Higher scores mean the payment is easier to defend, explain and recover if something goes wrong.
The most dangerous payment is the one nobody is required to confirm
Human approval should not be required for every $6 subscription renewal. That defeats the purpose of an autonomous agent.
But fully autonomous systems need clear escalation rules. Useful triggers include:
- a first-time beneficiary;
- a changed bank account or wallet address;
- an unusual country or currency;
- a transaction above a dynamic amount threshold;
- a beneficiary name mismatch;
- payment instructions received through a new communication channel;
- a contract or invoice the agent cannot independently reconcile; and
- irreversible rails above a defined loss tolerance.
Who should absorb the loss?
There will not be one universal answer. Liability will vary by jurisdiction, payment rail, contractual allocation and the exact failure.
But DN expects a durable principle to emerge:
If the bank executes exactly what the authorised agent instructed, the dispute should focus upstream. If the bank executes something different, the responsibility shifts. If the agent exceeded a technically enforceable mandate, the authorization provider matters. If the user explicitly approved the wrong beneficiary, existing payment rules may still dominate.
Why signed intent matters
The industry is moving toward machine-readable proof of what the user actually authorised. Google’s AP2 design, Visa’s trusted-agent work and Mastercard’s agent credentials all point toward richer authorization objects rather than a generic “this agent can pay” permission.
The stronger model is closer to:
“This agent may pay this merchant, for this purpose, up to this amount, before this time, using this funding source.”
That does not eliminate mistakes. It dramatically shrinks the space in which mistakes can become financially effective.
DN Alpha Thesis
Agentic payments will move the industry from account-level permission to transaction-level intent.
The most important infrastructure will not be the agent that can click “pay.” It will be the system that can prove what the principal meant, what the agent was allowed to do, what it actually did and whether the money can still be recovered.
The first major agentic-payment scandal is unlikely to be caused by a payment rail that failed technically.
It will be caused by a payment rail that worked perfectly on a bad machine decision.
Sources
- IMF — How Agentic AI Will Reshape Payments (2026)
- NIST — AI Risk Management Framework
- NIST CSRC — Cybersecurity Framework Profile for AI, preliminary draft
- NIST CSRC — SP 800-53 Rev. 5, access control and audit controls
- Visa — Trusted Agent Protocol
- Mastercard — Agent Pay and European agentic commerce
- Agent Payments Protocol (AP2)
FAQ
Who is liable if an AI agent sends money to the wrong person?
There is no universal answer. Liability depends on the payment rail, jurisdiction, contractual terms and whether the failure occurred in intent, authorization, beneficiary selection, execution or settlement.
Can payment limits prevent agent mistakes?
They reduce losses but do not prove the beneficiary or transaction is correct. A bad payment can still sit entirely within a valid spending limit.
Are crypto payments riskier for autonomous agents?
They can be harder to recover because settlement may be final quickly. Strong beneficiary verification, allowlists and escalation thresholds become especially important.
