Can an AI agent access your business bank account safely?

Direct verdict

Do not give an AI worker your bank login. Use a read-only connection that the bank has approved, and keep payments under the control of a named person. For reconciliations, payment reminders and cash reporting, a read-only feed is usually enough. The AI worker needs to see transactions and due dates. It does not need to move money.

This verdict rests on the current bank position, not on a view about any single product. The bank position is changing quickly, so check it again before you sign anything.

What changed in October 2026

Axios reported on 22 October 2026 that several large US banks were detecting outside AI agents inside customer accounts, in some cases using customer-supplied credentials. Reuters reported the same day, citing two people familiar with the situation, that major banks were blocking third-party agents from operating inside accounts and making transactions. The Financial Times has also reported that Citigroup and Bank of America are restricting AI agents.

Be precise about what is confirmed. Citi, JPMorgan Chase and Wells Fargo have made on-the-record statements about restricting access. Morgan Stanley's spokesperson said the bank had not observed rogue AI agents on its platforms, even though it has reportedly begun blocking third-party agents as a precaution. The reports describe banks restricting access. They do not confirm that rogue agents took money from customer accounts.

The banks' reasoning is about who is really acting. A bank can see which credentials were used to log in. It often cannot tell whether a person directed the activity. JPMorgan's chief executive, Jamie Dimon, told reporters that the bank would limit AI agents' access because of the risk of rogue agents, according to the Financial Times report. Citi's position is that third-party agents may not log in or transact directly, but customers may authorise limited, read-only access through Citi-approved open-banking providers.

Banks also point to their terms of service. Several reports say those terms require a human to log in directly, and that sharing a password with an unvetted agent can breach them. If the bank treats the activity as unauthorised, the payment may be flagged or blocked, and the question of who bears the loss is not settled. Bank of America's chief executive has said the bank is developing protocols to decide which party is liable for payments authorised by AI.

The US open-banking rule is on hold

You might expect a legal right to share bank data to cover this. In the United States, it does not work that way right now. The CFPB finalised its Section 1033 rule in October 2024, with a first compliance date of 1 April 2026. A federal court in the Eastern District of Kentucky has enjoined the CFPB from enforcing the rule while the Bureau reconsiders it. The CFPB has said it may revise or replace key parts.

A revised proposal reportedly went to the White House's regulatory review office on 6 August 2026. No revised rule is in force. For now, US data access runs on bank-by-bank agreements and existing privacy law. Other countries have their own frameworks. In the United Kingdom, Xero's own page says it is an FCA-authorised Account Information Service Provider, which gives it read-only access to bank account information when a customer asks for it. Australia uses the Consumer Data Right framework for read-only bank feeds.

Side-by-side comparison

The two options are not two products. They are two ways of letting software reach your bank data. The table compares them on the points an operations head usually asks about. Where a vendor does not publish a figure, the table says so.

What automation cannot do here

Automation cannot make a bank grant access that the bank has refused. If your bank blocks third-party agents, no workflow, script or agent can get around that block without breaking the bank's terms. Doing so would also expose the business to the liability question described above.

A read-only feed has its own limits. It shows what the bank has recorded. It does not know why a payment was made, whether a supplier invoice is correct, or whether a transfer was authorised on the business side. Someone still has to match ambiguous items and decide. Read-only feeds also depend on bank coverage, so some accounts will need statement uploads.

Who each option is right for

A login-based agent is only worth considering if the bank has approved it in writing and the business has a clear legal basis for it. For most owners reading this in late 2026, that condition is not met. Treat it as a closed door, not a risky shortcut.

A read-only feed suits almost any business that reconciles its books, chases payments or prepares monthly reports. A five-person firm with one current account and a bookkeeper gains the most from a single feed. A larger group with several entities, currencies and banks needs the same pattern, but with more accounts, more approvers and a clearer owner for each feed. The approach works at both sizes. What changes is the number of people who approve payments.

Some businesses should not automate the payment step at all. If a payment run involves disputed supplier balances, payroll, or tax payments with strict deadlines, keep the human decision and use automation only for preparation.

Total cost of ownership drivers

The sticker price of a feed is rarely the largest cost. Count these items before you choose.

1. Setup time. Someone has to map accounts, check opening balances and test the first two weeks of transactions against the bank statement.
2. Approval design. Deciding who approves a payment, up to what amount, and how a second approver is added takes a meeting, not a click.
3. Maintenance. Banks change connection rules, and a feed can stop without warning. Someone should check the feed status each week.
4. Breakage. When a bank connection fails, reconciliations stop. Budget for the manual catch-up.
5. Vendor lock-in. Check whether you can export transaction history and approval logs in a plain format before you commit.
6. Audit and records. Keep a log of who approved what, and retain it under your own record-keeping rules.

The custom-built alternative and when it wins

A custom build means a developer connects to a bank's approved interface or to an open-banking provider, and writes the matching, reminder and reporting logic for your business. It wins when your workflow is unusual, when several systems must share one approval trail, or when you need control over where data is stored. It loses when your needs are standard, because the build, testing and upkeep cost more than a packaged feed plus a clear approval step.

A custom build does not avoid the bank's rules. It still needs bank approval or a regulated provider for data access. Ask any builder to show the bank or provider agreement before work starts.

Migration notes

If you currently share a bank login with a tool, change it before anything else. Change the password, check the bank's list of authorised connections, and remove the old access. Then set up the read-only feed and run both in parallel for two or three weeks. Compare the balances each month. Keep the old export files until the first month-end close is signed off.

Set a rule that every payment needs a named approver. Record that name in the approval log. Review access every quarter, and remove people who have left.

This explains the rule in general terms; it is not legal or tax advice for your case.