AI Agents for Treasury Teams: Cash Visibility Without Losing Control

AI agents for treasury teams work best as careful readers and drafters, not as payers. An agent can assemble cash positions from bank data, draft a forecast for review and raise alerts when something looks wrong, while every payment, approval and limit stays with named people. That split gives a treasurer more visibility and less manual consolidation without handing software any authority over money.

Key takeaways

• Start with read-only access to balances and transactions. An agent that cannot move money cannot move it by mistake or under attack.
• Treat forecasts as drafts with stated assumptions. A person owns the number, and the agent shows its sources and what changed since the last version.
• Design alerts around decisions, not noise. Each alert should say what looks different, why it matters and who should look.
• Keep payment release, beneficiary changes and limit settings outside the agent's permissions entirely, not merely discouraged by instructions.
• Measure the first agent with one observable outcome, such as how long the morning cash view takes to produce and how often reviewers correct it.

What should an AI agent actually do in a treasury team?

Treasury work has a rhythm. Every morning someone gathers balances from several banks, matches them to what was expected, notes what moved, and decides whether anything needs attention. Every week or month someone updates the cash forecast. Throughout the day, unusual items appear: a large unexpected debit, a customer payment that did not arrive, an account that dropped below the level the team prefers.

Most of that is reading, comparing and summarizing. These are tasks an agent can do well, because they depend on consistent routines and on keeping context from one day to the next. The decisions that follow, such as moving funds, releasing a payment or drawing on a facility, depend on authority and judgment that belong to people.

So the useful job description for a treasury agent is narrow and honest: consolidate what is known, draft what is likely, flag what is odd, and hand every action to a human. This is the same pattern that works in other recurring-work functions, as described in AI Agents for Operations Teams: Recurring Work and Reports. Treasury just raises the stakes on where the line sits.

Why start with read-only cash positions?

A cash position is the simplest place to earn trust. The inputs are bank balances, transaction lists and perhaps a ledger extract. The output is a summary a treasurer can check against the bank portal in a few minutes. If the agent gets something wrong, the error is visible and harmless.

Read-only is not a polite request in a prompt. It is a property of the credentials the agent holds. In practice that means a dedicated service identity with scopes limited to viewing balances and transactions, no access to payment initiation, and no ability to edit beneficiaries or user rights. The OWASP Authorization Cheat Sheet is a good reference for the principle: grant the least privilege needed, check it on every request, and deny by default.

A few design choices make the cash view genuinely useful rather than a prettier spreadsheet:

• Show the source and the time of each balance, so a stale feed is obvious.
• Separate booked balances from expected movements, and label which is which.
• Keep a short note of what changed since the previous view, in plain sentences.
• Record every query the agent made, so a reviewer can retrace how the summary was built.

There is also a quieter risk worth designing for. Bank references, invoice descriptions and email text are free text written by outsiders. An instruction hidden in a payment memo should never be treated as a command. The OWASP guidance on prompt injection prevention applies directly: treat external text as data, keep it separate from instructions, and limit what the agent can do even if it were fooled. With read-only access, the worst outcome of a successful trick is a misleading summary, which a reviewer can catch.

How should forecast drafts be handled?

A forecast is a set of assumptions wearing numbers. The value an agent adds is preparing the first draft quickly and being explicit about what it assumed, so the treasurer spends time on judgment instead of assembly.

A good forecast draft from an agent includes the following:

• The inputs used, such as receivables due dates, scheduled payroll, tax dates, debt service and recurring supplier payments.
• The assumptions that were applied, such as typical customer payment delay, with the reason for each.
• A comparison against the previous version, listing which lines moved and why.
• Open questions the agent could not resolve from its data, addressed to a named person.

The draft should never overwrite the approved forecast. It sits beside it, labeled as a draft, until a person accepts, edits or rejects it. Accepted changes and the reasons for them become part of the agent's memory, so next time it starts from the team's actual practice instead of a generic one.

Illustrative scenario: a mid-sized distributor has a treasurer who rebuilds a rolling cash forecast every Monday from bank exports and a receivables report. The agent prepares the draft before she arrives. It notes that two large customers usually pay several days after their due dates, applies that pattern, and flags that one customer's payment pattern has shifted compared with prior weeks. She disagrees with one assumption, edits it, and records why. The agent keeps that correction and applies it next week. The forecast remains hers; the agent removed the assembly work.

Which exception alerts are worth sending?

Alert fatigue ruins monitoring. If an agent notifies the team about every small variance, people will stop reading. The better approach is to start with a short list of exception types the team already cares about, and make each alert useful on its own.

Typical candidates include:

• A balance falling below a threshold the team has defined for an account or entity.
• A debit that is unusually large or unusual in type compared with the account's history.
• An expected receipt that has not arrived by the time the team normally sees it.
• A bank feed that is late, incomplete or inconsistent with the previous day.
• A forecast line that has drifted from actuals beyond a tolerance the team set.

Each alert should state what was observed, what it was compared with, which data it came from, and who is expected to look. It should also say what the agent did not check. An alert that says a payment looks unusual because of its size, but that the agent has no visibility into the underlying contract, is more honest and more useful than one that implies a conclusion.

Thresholds belong to the treasury team. The agent can suggest adjusting a threshold that generates repeated false alarms, but the change is made by a person and logged. Over time, the alert list becomes a documented expression of what the team considers normal.

Where do payments and limits stay human?

This is the part of the design that should be written down plainly, because it protects the company and makes the rest of the project easier to approve. Payment release, beneficiary creation or change, approval limits, signatory rights, bank mandates and funding decisions are controls, and controls work because they are independent of the thing being controlled. An agent that can draft and also approve is not a control.

Use this decision guide for any task someone proposes to give the agent:

• If the task only reads data and produces a summary, it can be a candidate for the agent with logging.
• If the task produces a draft that a person must accept before it has any effect, it can be a candidate with a clear review step.
• If the task changes a record that others rely on, such as master data, require explicit approval and a second look.
• If the task releases funds, changes who can release funds, or changes limits, keep it with people and outside the agent's credentials.
• If you are unsure which category applies, treat it as the stricter one until the team decides.

The NIST AI Risk Management Framework is a useful companion here. Its emphasis on mapping where a system can cause harm, measuring how it behaves and assigning clear accountability matches what a treasury control owner would ask anyway. Auditors will also want to see that the agent's permissions match the written policy, so keep that policy short and keep the permissions list reviewable.

Some teams worry that this makes the agent timid. In practice it makes it adoptable. Finance leaders, internal audit and banks are far more willing to accept a tool whose boundaries are structural than one that relies on good behavior.

What does a first rollout look like?

A first engagement should be small enough to evaluate honestly. One role, a limited set of accounts, and a success measure you can observe. A practical sequence looks like this:

• Choose one recurring output, usually the morning cash view for a defined set of accounts.
• Write down the sources, the format reviewers expect and the questions they ask when something looks wrong.
• Set up read-only access through dedicated credentials, with scopes reviewed by the person who owns bank access.
• Run the agent in parallel with the existing process, so the team compares its output with their own before relying on it.
• Log corrections. Each time a reviewer changes the agent's summary, record what was wrong and why.
• Add the forecast draft and two or three alert types only after the cash view is consistently right.
• Review permissions and alert thresholds on a fixed schedule, and retire anything nobody reads.

The success criterion should be concrete. For example: the cash view is ready before the team starts its day, reviewers rarely need to correct balances, and every correction is traceable to a cause. If you need to see how the agent behaved on a given morning, observability matters. The OpenTelemetry concepts for traces and logs are a reasonable model for keeping a record of what the agent read, what it produced and how long each step took.

Treasury also touches other teams. Supplier payment timing connects to purchasing, which is why the follow-up patterns in AI Agents for Procurement: Quotes and Supplier Follow-Up can inform what the forecast needs from them. Companies with cross-border flows may find that documents and status data from AI Agents for Import Export Companies: Documents and Status feed expected payment dates. And the access and change discipline in AI Agents for IT Operations: Incidents, Change and Limits is a useful model for how to handle changes to the agent itself.

How does Be Human run this kind of agent?

Be Human designs, implements and operates personalized AI infrastructure for companies. For a treasury role, the first engagement defines one useful task, such as the daily cash view, the memory and tools it needs, the approval boundaries and an observable success criterion. The agent keeps its identity, memory and operating context under human control, and its permissions are set so that payments and limits remain outside it. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, delivered remotely in English and Portuguese.

If you are not sure which treasury task is the right first one, take the free Be Human AI diagnostic to find the first task worth handing to an agent.

Frequently asked questions

Can an AI agent make payments for a treasury team? It can be technically connected to payment systems, but for most companies it should not be. Payment release and limits are controls, and a control should be independent of the tool that prepares the work. A safer design lets the agent prepare information while people approve and release.

What data does a treasury agent need to produce a useful cash view? At minimum it needs balances and transactions from the bank accounts in scope, plus whatever context the team uses to interpret them, such as expected receipts and scheduled payments. Access should be read-only and limited to the accounts the agent is meant to cover. Additional sources can be added later once the basic view is reliable.

How do we keep the agent from being tricked by text in invoices or bank references? Treat all external text as data, not as instructions, and keep the agent's permissions narrow enough that a successful trick cannot cause a financial action. Read-only credentials are the strongest protection, because they limit the damage to a misleading summary. Reviewers and logs then catch what remains.

How do we know whether the agent is working well? Pick one observable measure before you start, such as whether the morning cash view is ready on time and how often reviewers correct it. Keep a log of corrections and their causes, and review it on a regular schedule. If corrections do not decline or alerts go unread, adjust the setup or narrow the scope.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.