Read access, yes; release rights, no. A finance agent should see balances and transactions on the company's bank accounts so it can reconcile, forecast cash and prepare payments. It should not hold a bank user that can release payments, add payees or change mandates. Those steps stay with named signatories, each approving in the bank's own channel.
What does the agent need bank data for?
Most of the useful finance work involving bank accounts is reading. Matching statement lines to the ledger, explaining unreconciled items, building the daily cash position and spotting duplicate payments all depend on seeing the bank feed. None of them requires the power to move money.
That asymmetry is the point made in finance agents need read access to more than they can change. Wide reading makes the agent useful. Narrow writing keeps it safe. Our guide to reconciling bank accounts to the general ledger with an AI agent shows what that reading supports in practice.
What conditions decide how far access goes?
- How the data reaches the agent. A bank statement feed into the ledger or treasury system is better than a bank portal login. The agent should read from your system of record, not sit in the bank's channel.
- Which accounts. Operating accounts are usually in scope. Accounts held for clients, escrow or trust money may carry extra duties and should be scoped separately.
- Who the agent is. It needs its own identity, so the bank and your auditors can see that a machine read the data, not a person.
- Whether payment preparation is needed. If yes, the agent prepares a file or a draft in your payables system. Release happens in the bank, by people.
What may the agent do, and what stays with a person?
| Task | The agent | Stays with a person |
|---|---|---|
| Read balances and statements | Reads through the feed (depth 1) | None |
| Reconcile to the ledger | Matches and drafts explanations (depth 2 to 3) | Writing off differences |
| Cash position and forecast | Drafts daily (depth 2) | Funding and investment decisions |
| Prepare a supplier payment run | Drafts the run (depth 2) | Releasing it in the bank |
| Transfers between own accounts | Proposes the sweep | Approving and releasing it |
| Add a payee or change details | Nothing | A signatory, with call-back checks |
| Change bank mandates or users | Nothing | Directors and the bank |
Moving money between the company's own accounts looks harmless, but it is still money movement and it is where fraud often hides. We cover it in whether an AI agent can move money between company bank accounts.
A worked example
Take a retailer with six bank accounts across two banks. The agent reads both feeds every morning. It matches card settlements to sales, flags a direct debit that has doubled since last month, and drafts the cash position for the treasurer.
Midweek, an email arrives that appears to come from a supplier, asking for payment to a new account. The agent cannot change payee details and has no bank user, so the request goes to the payables manager, who calls the supplier on the number already on file. The account change was fraudulent. Had the agent held a bank login with payee rights, the only protection would have been its own judgement about an email. We explain why this is the place to stop in supplier bank detail changes are where finance agents must stop.
Which controls make the answer hold?
- No bank credentials for the agent. It reads through a feed or an interface with read-only scope. If a bank only offers portal access, a person downloads the statements.
- Release in the bank, by people. Dual authorisation in the bank's own channel stays exactly as it is.
- External claims cannot authorise payments. An emailed instruction is external information. It can prompt a check, never a payment.
- A filed record of every read and proposal. So you can show what the agent saw and what it suggested.
- Access review. Bank-related scopes are reviewed alongside human bank users, at the same frequency.
The topic guide AI agents for finance: books you can audit places these controls in the wider design.
Where Pryme fits
In Pryme, facts reaching an agent carry provenance. A bank feed from your system of record is sealed; an emailed payment instruction is external, and an external claim cannot authorise a payment. Moving money is depth 4, granted only on evidence from your own cases, and your own limits can hold every payment for a named approver.
Questions people ask
Can the agent log into the bank portal to download statements?
It should not. A portal login usually carries more rights than reading, and sharing one breaks the bank's assumption that a known person is using it. Use a feed or have a person download.
What about virtual cards for small purchases?
Treat a card as a payment capability with its own limit, merchant restrictions and owner. It is still money movement, so the same evidence rules apply.
Should the bank know an agent is reading the data?
Yes, where your bank agreement or feed set-up asks who accesses data. Being open about it avoids disputes later.