Would You Let an AI Agent Manage Your Business Money?
AI is moving from answering questions towards preparing and taking actions. Finance is a useful place to examine that shift: a wrong answer can be corrected, but an incorrect payment may be difficult to recover. The business question is not whether AI should manage money. It is which parts of a financial process are suitable for assistance, what authority is justified and how a person remains accountable.
From assistant to agent: four different levels
A system that answers a question about a spreadsheet is not the same as one that can change a financial record. An assistant may explain a report. An analytical tool may compare transactions and flag anomalies. A task-oriented agent may prepare a payment run or a reminder for review. An agent with execution authority may send a payment or update a ledger. Each step adds a different level of consequence, so “using AI in finance” is too broad to be a useful risk description.
Recent reporting by Axios described US banks detecting third-party AI agents operating within customer accounts, including cases involving user credentials and some activity that appeared independent of instructions. This is a reported account, not evidence that banks generally permit autonomous banking or that money was moved in every case. The distinction matters: a credential can provide a route into an account without granting the institution’s approval for an agent to use it.
Useful finance work does not require unrestricted control
There are practical areas where assistance may be worth testing: categorising expenses, extracting invoice details, matching payments to invoices, preparing a cash-flow summary, spotting unusual entries or drafting an overdue-payment reminder. These are examples of possible workflows, not a claim that a particular banking platform supports them. The system may reduce repetitive preparation, while a finance professional checks context, exceptions and the final decision.
A useful starting point is to separate the information an agent may read from the actions it may take. Read-only access to an approved export is different from permission to amend accounting records. Preparing a payment file is different from releasing funds. An organisation can often test whether analysis is useful before connecting a live account or granting write access. The first pilot should answer a business question, not simply demonstrate that an agent can click through a finance application.
Match authority to the consequence
A simple authority ladder helps make the decision explicit. At Level 1, observe and recommend: the system analyses information and suggests what a person should inspect. At Level 2, prepare and request approval: it assembles an action, but a named person reviews and authorises it through the normal process. At Level 3, execute within defined limits: it performs a narrow, low-risk action under explicit permissions, transaction limits, monitoring and a tested stop process.
Level 3 is not automatically appropriate because a task is repetitive. Suitability depends on the value at stake, the reversibility of an action, platform controls, contractual conditions and whether the business can detect a problem quickly. A threshold should define more than a maximum amount: specify permitted payees, purpose, frequency, evidence required, exception routing and who can suspend the process. If a bank or supplier does not support the required control, the design must respect that limitation rather than work around it.
Design for errors, manipulation and accountability
Risks include incorrect invoice details, duplicate payments, poor source data, integration failures and instructions hidden in material the agent reads. A malicious or misleading message could try to redirect a payment or persuade a system to ignore its usual checks. A model can also produce a plausible explanation for a conclusion that is wrong. Controls therefore need to exist around the whole workflow: data quality, identity, permissions, approval, logging, reconciliation, escalation and recovery.
Keep separation of duties where it already protects the business. The person or agent preparing a payment should not automatically be the only authority able to release it. Record what information was used, what the agent proposed, who approved it and what happened next. Agree who owns exceptions and how to stop the workflow. Consider bank terms, accounting requirements, insurance conditions, customer commitments and the organisation’s own policies. Technology does not transfer responsibility away from the business or the people accountable for its finances.
Measure the full commercial case
Before a pilot, record how much staff time the process takes, how often it occurs, what errors or rework are already present and how quickly exceptions must be resolved. Compare that baseline with the time spent configuring the workflow, checking results, handling failures and maintaining integrations. A faster preparation step may still be worthwhile even if every payment needs human approval, but the value should be described accurately as capacity or turnaround improvement rather than an assumed cash saving.
Also estimate the exposure if the system makes a mistake: could a payment be recalled, would a supplier relationship be affected, and what would investigation and remediation involve? Set a stop condition in advance. If review effort cancels out the time saved, accuracy is inadequate or the process cannot be paused safely, do not expand it. This is consistent with the broader decision-rights approach in When AI Starts Making Decisions and with the real cost of business AI.
Give AI enough authority to help, not more
A sensible first step is to map one bounded finance workflow, identify the information and systems involved, and decide whether the first test should be read-only or approval-based. Confirm that a human can understand the recommendation, that the workflow cannot silently exceed its remit and that there is an owner for monitoring and exceptions. Only move towards limited execution when the controls are supported, tested and proportionate to the potential benefit.
The objective is not to give AI more authority. It is to give AI exactly enough authority to create value without introducing unacceptable risk. An Altitude AI Discovery Review can help identify suitable processes, realistic savings and the controls required before deployment.