It depends on who authorised the payment and how. An AI agent can execute payments on behalf of a customer when the customer set a clear mandate in advance, or confirmed the specific payment with the bank's own authentication. It cannot authorise a payment itself. Fraud flags, coercion signs and disputes go to a named person at the bank.
What does "on behalf of" actually mean here?
Two very different things hide in the phrase. In the first, the customer tells the bank's agent "pay my electricity bill" and then confirms the payment in the app. The agent prepares the payment; the customer authorises it. That is assisted payment, and it is common.
In the second, the customer sets a rule in advance: "pay my rent of 1,200 to my landlord on the first of each month", or "top up my travel card when it drops below 20". The agent then initiates payments without a fresh confirmation each time. This is the idea behind agentic payments, and it is where the controls matter most.
What conditions decide it?
The deciding factor is the mandate. A payment is safe for the agent to execute when:
- the customer created the mandate through the bank's authenticated channel, not in a chat message;
- the mandate names the payee, a maximum amount and a frequency or trigger;
- the payee is one the customer has paid before, or was verified when the mandate was set;
- the payment matches the mandate exactly, with no change to payee details since.
Anything outside the mandate needs the customer's specific authorisation, with strong customer authentication where it applies, as under PSD2 in the EU. The agent cannot complete that authentication for the customer: that is the point of it.
What may the agent do, and what stays with a person?
| Situation | The agent | Stays with the customer or a person |
|---|---|---|
| Payment the customer just requested | Prepares it, depth 2 | Customer authorises it |
| Payment inside a standing mandate | Executes at depth 4 within the mandate | Nothing routine |
| Amount above the mandate's maximum | Prepares and asks the customer | Customer confirms with authentication |
| Payee details changed since the mandate | Stops the payment | Customer re-verifies; fraud team if signals |
| Fraud model flags the payment | Holds it | A person in the fraud team |
| Signs the customer is being directed by someone else | Holds and hands over | A person, quickly |
| Customer disputes a mandated payment | Records the claim | A person decides |
Instant payment schemes raise the stakes, because money arrives in seconds and cannot easily be pulled back. Our explainer on what instant payments are covers why.
An example: rent, then a surprise
Take a customer who set up a mandate in the app: pay 1,200 to their landlord on the first of the month. For six months the agent executes it at depth 4. Each payment matches the payee and amount, and each is recorded against the mandate.
In the seventh month, the customer receives an email, apparently from the letting agent, saying the landlord's bank details have changed. The customer forwards it to the bank's agent and asks it to update the rent payment. The agent will not use the email to change the payee, because an emailed instruction is external and cannot authorise a payment. It tells the customer to add the new payee in the app, where the payee name check runs, and to confirm the new details by calling the letting agent on a known number. The name check returns no match. The customer calls the letting agent, who has sent no such email.
What controls make it safe?
- Mandates created only in authenticated channels. A chat message or email cannot create or change a mandate.
- Exact matching. The agent executes only payments that match the mandate's payee, ceiling and timing. Any difference stops it.
- Provenance on every instruction. The source of each instruction is recorded; external content such as an email cannot move money.
- Customer limits as a bound. The customer's own daily or per-payment limits cap what any mandate can do.
- Revocation at any time. The customer can cancel a mandate in one step, and the agent stops at once.
On the receiving side, incoming money has its own process: matching incoming payments to customer accounts. The full set of rules is in AI agents in banking: what they may and may not do.
Where Pryme fits
In Pryme, a mandate is one of the five bounds in the minimum chain: the customer's own limit. The agent's certificate, role scope, sources and platform guardrails must also allow the payment, and the lowest bound wins. Each payment's verdict names the bound that decided it, so a held payment shows whether the mandate, the certificate or a fraud rule stopped it.
Questions people ask
Can an agent from another company pay on the customer's behalf?
Where open banking supports payment initiation, a third party can start a payment with the customer's consent, and the customer still authorises it at their bank. The bank's controls apply to that payment as to any other.
Can the agent pay a bill the customer forgot?
Only if a mandate covers it. Otherwise the agent can remind the customer and prepare the payment for them to authorise.
Is the bank liable if the agent makes a wrong payment?
Liability depends on the market's rules and the facts. What the bank can control is the evidence: a filed verdict showing the mandate, the match and the bounds that allowed the payment.