AI Agents and Business Banking: Who Controls the Money When Software Can Act?

An AI tool that explains a bank statement is very different from software that can move money. For a UK business considering financial automation, the important question is not whether the agent sounds reliable. It is what authority the connected systems actually give it, who approved that authority and how the business can withdraw it.

Payment providers are developing agent-enabled commerce. Visa describes payment controls, authentication and permissioned transactions within its Intelligent Commerce portfolio. Its page also warns that the product is in deployment and final features may differ. This is evidence of a developing payment model, not proof that a particular agent can access your business bank account or that every integration is available in the UK.

From banking assistant to financial agent

Separate five activities before approving a connection. Reading financial information exposes balances, counterparties and transaction history. Categorising transactions changes accounting records. Preparing a payment instruction creates a proposed action. Initiating a payment submits that action to a payment service. Authorising it gives the final approval required by the relevant workflow. Some platforms combine steps; your control design should not assume they are separate.

A read-only connection may be appropriate for reporting while payment access is unnecessary. A draft invoice or payment file should not silently become an instruction to pay. Record what the agent needs to do, which accounts it can reach and which decisions must remain with authorised people.

Where financial automation can go wrong

Excessive permissions can turn a narrow task into broad account access. Credentials copied into prompts or configuration files can escape their intended boundary. A compromised integration may misuse an otherwise legitimate connection. Weak authentication and shared accounts make it harder to identify who or what acted.

Prompt injection is another concern: an agent may encounter hostile instructions inside an invoice, email or web page and mistake them for authorised directions. Untrusted content must not be allowed to redefine payment rules. Inadequate logs can then leave the business unable to explain a transaction, while long-lived sessions or tokens make prompt revocation difficult.

Build controls around the payment, not just the prompt

• Least privilege: request read-only access where sufficient and restrict accounts, actions and data to the agreed purpose.
• Separate identities: use a dedicated service or application identity where supported, rather than borrowing a director's everyday account.
• Secure connections: use supported integrations and appropriate authentication; keep credentials and tokens in controlled storage, outside prompts and routine logs.
• Payment limits: enforce thresholds, permitted recipients and transaction limits in the financial platform or a separate policy control, not solely in the agent's instructions.
• Separation of duties: do not let the same automation create a supplier, change its bank details and approve its payment without independent checks.
• Human authorisation: retain meaningful review for high-risk actions, with clear information about the recipient, amount, account and reason.

MFA helps protect human administrators and approvers. It does not automatically secure every machine-to-machine connection, API token or existing session. Ask how the specific integration authenticates, how tokens expire and what happens when an administrator's access changes.

Make approval a real decision

An approval button is weak protection if the reviewer sees only the agent's summary. Present source records and independently verified beneficiary details. A new payee, changed bank account or unusual request should trigger a separate verification procedure using trusted contact information. Urgency is a reason to follow that procedure, not bypass it.

Keep an audit trail linking the initiating identity, proposed action, policy decision, human approval and eventual transaction result. Reconcile records against the financial system. Alerts need a named owner and an escalation route; collecting logs without reviewing exceptions is not effective oversight.

Test the boundaries without moving real money

Use a provider-supported sandbox or an isolated test environment with synthetic records. Check that the agent cannot exceed its limit, select an unapproved payee or act on instructions embedded in an invoice. Test rejection as well as success. Confirm the proposed action and approval history are recorded accurately.

Practise stopping the integration: disable the identity, revoke credentials and tokens, and check whether existing sessions or queued instructions survive. A kill switch that only closes the chat window may leave the financial connection active. Record who can stop it and how the business confirms access has ended.

The independent assurance question

Can you produce a current list of agents and applications with financial-system access, their owners, permissions, approval rules and last review date? Review these when tasks, suppliers or personnel change. Our wider AI-agent governance guide covers ownership; this financial review should establish the actual payment authority behind it.

Altitude IT can review technical identities, integrations and access controls within an agreed scope through independent IT advice and reviews. That is not regulated financial advice or an audit of a bank's own systems. An AI agent should never have more financial authority than your business has deliberately approved and can independently verify.

Primary source

Visa Intelligent Commerce: capabilities and deployment disclaimer. Source checked 2 November 2026. No specific banking-loss incident is asserted in this article.