Can an AI agent actually execute a payment, or does it only prepare one?
Copied! Can AI agents release payments alone? What a CFO should ask about the control layer between an agent's draft and a named human's approval.
No.
In a properly controlled finance operation, an AI agent does not release money on its own. It reads, reconciles, drafts and flags. A named human decides whether the payment actually goes out.
That is not a gap the technology will eventually close. It is the design a sceptical finance team should insist on, because the real question was never whether the model is clever enough - it is who answers for the payment once it has left the account, and that question already has an owner:
Under the Companies Act 2006, a director must exercise reasonable care, skill and diligence running the company (section 174). Nothing in that duty moves to a piece of software because the software produced the draft.
The FCA has said much the same about AI specifically: its existing rules on senior manager accountability "are relevant to the safe use of AI" (FCA, AI and the FCA: our approach).
The person who approves still carries the responsibility, whatever tool produced the recommendation.
TL;DR
- No. In a properly controlled finance operation an AI agent prepares a payment and a named human releases it.
- Under section 174 of the Companies Act 2006 a director's duty of care does not move to software because the software produced the draft.
- A payment run has five layers: reading and reconciling, drafting, validating against policy, flagging exceptions, and releasing. An agent suits the first four.
- Ask a vendor four things: what the agent can see, what it can draft, what it can never release without a named approver, and what it logs.
- The four failure modes worth naming are confident wrongness, stale data, prompt-driven mistakes and over-broad permissions.
- Agents earn their place in exception work, not at the release step.
Explore Round's connected treasury platform
What are the five layers of a payment run, and why is one of them different?
Strip a payment run down and it is really five separate jobs, not one:
- Reading and reconciling. Pulling in bank feeds, matching transactions to invoices and purchase orders, spotting what does not tie out.
- Drafting. Turning matched, approved items into a proposed payment run: who gets paid, how much, from which account.
- Validating against policy. Checking the draft against spend limits, approved supplier lists, entity rules and anything else the finance team has set.
- Flagging exceptions. Surfacing anything that breaks a pattern: a new payee, a changed IBAN, an amount well outside the usual range for that supplier.
- Releasing. Actually instructing the bank to move the money.
The first four are preparation. An agent can do all of them well, fast, and across far more entities and banks than a person could keep in their head at once.
The fifth is different in kind, not just in degree. It is irreversible in practice, even where a reversal process technically exists, and it happens on rails built for speed.
The Payment Systems Regulator's rules on authorised push payment scams, which took effect on 7 October 2024 and set a maximum reimbursement of £85,000 per claim, exist precisely because money that has already moved is hard to get back and someone has to bear that cost when it goes wrong (PSR, PS24/7).
Release is the one step where a mistake stops being a correction and starts being a loss. That is why it should never be the step an agent completes alone.
What control surface should a finance team demand?
"Agentic" is doing a lot of work as a marketing word right now, and it can mean almost anything from a smarter search box to a system that genuinely takes actions. Before trusting any of it near a bank account, ask a vendor to be specific about four things.
What can it see? Read access to bank feeds, the ledger, invoices and supplier records is reasonable and is where most of the value sits. Be clear about which systems that read access actually reaches, and whether it is scoped per entity or blanket across the group.
What can it draft? Payment runs, reconciliation matches, exception summaries, policy checks. All useful, all reviewable, all reversible with no cost if wrong.
What can it never release without a named approver? This should be an explicit, non-negotiable list: the payment run itself, any change to a supplier's bank details, any override of a flagged exception, any change to who is allowed to approve what. If a vendor cannot draw this line clearly, that is the answer to the original question.
What does it log, and would that log survive an audit? Not "an activity feed", a record that ties a specific action to a specific named person, a timestamp, and the data that decision was based on. An auditor, or a court, is not interested in "the agent approved it". They want to know which human did, and on what grounds.
This is the same logic finance teams have used for years with maker-checker controls on payments, where one person prepares a payment and a different, senior person reviews and releases it. An agentic tool does not replace that principle. It should sit entirely on the maker side of it.
Where do agents earn their place?
None of this is an argument against agentic tools in finance. It is an argument for putting them in the right seat. The place they earn that seat is exception work: the unglamorous, error-prone, easy-to-miss checking that eats into a finance team's week:
- Matching thousands of transactions to invoices across multiple entities and banks.
- Spotting the mismatch across entities that a spreadsheet built for one company was never designed to catch.
- Chasing a supplier for a missing document, noticing that a payment amount has drifted from the usual pattern for that vendor.
These are jobs an agent can do continuously, at a scale no team can match, and jobs where being wrong occasionally costs almost nothing because a human reviews the output before anything happens. That is the kind of work worth automating.
Take a founder running three subsidiaries with accounts at two different banks. Each entity has its own invoices, its own supplier list and its own bank feed, and by the time month end arrives, spotting which entity actually paid a shared supplier twice is the kind of task a person only catches by accident, usually late, usually under pressure.
An agent working continuously across all three feeds can surface that duplicate the same day it happens, and hand a finance lead a short, specific exception to check rather than a spreadsheet to comb through. The finding still goes to a person. The finding, not the fix, is what the agent is good at.
What are the four failure modes worth naming?
A tool that only tells you what it does well is not being straight with you. Four things go wrong with agentic finance tools in practice, and naming them plainly is more reassuring than pretending they do not happen.
Confident wrongness. A model can produce a clean, well-formatted, entirely wrong answer with the same tone it uses for a correct one. A misread invoice line, a transaction filed against the wrong entity, or a currency mismatch on a multi-currency payment does not come with a flashing warning attached. It reads exactly as tidy as the correct version.
Stale data. A draft is only as good as the feed underneath it. A delayed bank feed or a lagging ledger sync means the agent can be working confidently from information that is already a few hours out of date, proposing a payment run against a balance that has since moved.
Prompt-driven mistakes. Text embedded in an invoice, an email or a document can be written to steer an automated system toward an action it should not take, for instance an invoice attachment carrying instructions that look like legitimate updated payment details. This is the same family of manipulation behind a lot of push payment fraud, aimed at a system instead of a person.
Over-broad permissions. An agent set up with more access than its actual job needs turns a small mistake into a large one: a tool that only needs to read a ledger and draft a summary has no business holding the credentials that could also change a payment threshold. The fix is not distrust of the technology. It is scoping access to the job, not to what is technically possible.
What each kind of task actually needs
The pattern holds across every row. Reading, matching and flagging sit comfortably with an agent working alone, because being wrong there costs a review, not a loss. Anything that changes where money goes, or who is allowed to release it, needs a name attached before it happens.
What should you ask in the demo?
Most sales demos are built to show the agent at its best: the tidy payment run, the fast reconciliation, the exception caught in seconds. That is worth seeing, but it is not the part that determines whether the tool is safe to put near a bank account. A useful demo answers these:
- Show me the exact screen where a payment is released, and whose login that action sits under.
- What can the agent see, draft and release, in writing, not in general terms?
- What happens if someone, or something, tries to change a supplier's bank details through the system?
- Can I see the approval log for the last twenty payments, and would it hold up if an auditor asked who approved what and why?
- When the agent is confident and wrong, who catches it, and how long does that take?
If a vendor answers all five without reaching for a caveat, that is a genuinely good sign. If any answer turns vague exactly at the release step, that vagueness is the actual product.
Round is built around the layers this article describes: automation that reads, prepares and surfaces exceptions across entities and banks, with the release step kept with a named approver.
That is not the only way to build an agentic finance tool, and it should not be taken on trust either, here or anywhere else. For how the mechanism behind that actually works, from bank feeds through to a finished payment run, see how an AI-orchestrated treasury actually works. Whichever tool a finance team ends up choosing, the test is the same: ask where the drafting stops and the deciding starts, and make sure a person you can name is standing at that line.
Sources
Frequently Asked Questions
Not in a properly controlled setup. An agent can read data, draft a payment run and flag anything unusual, but the release step, the moment money actually moves, should always sit with a named human who is accountable for that decision. Any tool that skips this is asking a finance team to hand over more trust than the situation warrants.
Drafting produces a proposed payment run built from matched invoices, approved suppliers and policy checks. It can be reviewed, edited or rejected with no consequence. Executing releases funds through the banking rails. Once that happens it is very hard to reverse, which is why the two steps need different levels of control.
The named human who approved it, and the company's directors more broadly. Under the Companies Act 2006, a director must exercise reasonable care, skill and diligence running the company (section 174), a duty that does not transfer to software because software produced the draft. Good agentic tools are built around that fact, not around it.
Ask exactly what the tool can see, what it can draft, what it can never release without a named approver, and what it logs. Then ask whether that log, who approved what, when, based on which data, would satisfy an auditor. If a vendor cannot answer all four plainly, treat that as the answer.
Agents are genuinely useful at surfacing the things a busy team misses: a changed bank detail, a duplicate invoice, an amount that does not match the pattern for that supplier. That is detection and it is valuable. It is not the same as prevention, and no tool removes the need for a human to check before money moves.
