Payment controls for AI agents

Financial Stability Board · Consultation response ·

Identifies duplicate payment after a network retry as a distinct risk in AI-initiated transactions. Recommends checks on repeated instructions, delegated authority and spending limits, drawing on established payment interfaces and UK Open Banking.

Read the response and attachments on fsb.org (PDF, 59 pages)

The document

Title
Response to the consultation report Sound Practices for Responsible Adoption of Artificial Intelligence (AI)
Consultation
Sound Practices for Responsible Adoption of Artificial Intelligence (AI), June 2026
Questions answered
Questions 1, 2, 3, 4 and 7, with general comments at Question 8
Capacity
Personal capacity
Submitted
Length
59 pages with attachments; the response runs to numbered paragraphs 1 to 29

The risk it names

The consultation’s list of agentic risks describes an agent that goes wrong, or is made to go wrong: unauthorised actions, erroneous actions, data breaches, disruption to connected systems. The risk this response adds is an agent doing the right thing twice.

Agents call interfaces over networks that time out and drop connections, and a client that times out cannot tell whether its call succeeded. The retry that follows is routine operation. Where the retried call moves money, it produces a second payment for a single intended instruction unless something specifically prevents it.

Three features make this heavier in the agentic case. No human sits at the point of execution to notice the duplicate. The duplicate is a well-formed, authorised-looking request, so it passes every check not looking for a repeat. And it recurs at machine frequency, unattended, until something stops it.

What it recommends

  1. Bind each payment-initiating instruction to a request key. The agent supplies a key with the instruction; the receiving system records the key with the result under a uniqueness constraint; a repeat of the same key returns the original result and initiates no second payment. A retry then costs nothing beyond the call itself.
  2. Enforce the controls in order: authority, then payment, then work. One validation step confirms that the credential is authentic, that the request falls inside what the principal authorised, and that the payment authorisation is fresh. Only then does money move. A check that runs after the money has moved does not prevent the loss.
  3. Write the human-defined scope as a mandate a system can check. A spending cap per transaction and cumulative, an authorised scope, an expiry, the identity of the agent holding the authority, and the threshold at which a transaction must be re-approved by a human.
  4. Pair the kill switch with an authority expiry. A kill switch requires a human to act to stop the agent. An expiry requires a human to act to keep it running. The second is the safer default because it does not depend on anyone noticing that something has gone wrong.

The mandate structure is already live in a supervised UK system. A UK Open Banking Variable Recurring Payment consent carries a maximum individual payment amount, periodic spending limits and a validity window, authorised once under Strong Customer Authentication and enforced thereafter by the bank that holds the account.

Four terms it asks the glossary to add

  1. Idempotency of an instruction. A repeated instruction produces the same result as the first and has no additional effect.
  2. Mandate. A delegated authority granted by a human principal, carried with the request and evaluated before execution.
  3. Authority expiry. The time after which a mandate ceases to authorise anything, with no human action required.
  4. Fail closed. A validation step that refuses a request whenever any required element is absent, expired or unverifiable.

Sources