How to let an AI agent prepare cash positions in your treasury system

Split the treasury system's rights into three and give the agent only two. It may read bank statements and balances, and it may write forecast and position entries. It may not enter deals or initiate payments. Funding moves it proposes are held for the treasurer, and every entry it writes is logged against its source.

What does a treasury system hold, and who owns the position?

A treasury management system pulls statements from banks, holds the cash position by account, entity and currency, records deals such as deposits, loans and FX contracts, and often connects to banks to send payments. Those functions sit side by side in one application, which is why access to "the TMS" is never a single decision.

The treasurer owns the daily position and every decision based on it: whether to sweep, fund, borrow or invest. Treasury operations usually prepare the position early each day, before markets and payment cut-offs. That preparation is the agent's work; the decisions are not. Moving cash between accounts is depth 4, and treasury is where irreversibility is sharpest.

The process itself, step by step, is in preparing daily cash positions with an AI agent. This playbook covers what the agent may do inside the system.

Which capabilities do you grant, and at what depth?

1. Agent, depth 1: reads statements and balances. Prior-day and intraday statements as the system receives them from the banks.
2. Agent, depth 1: reads known flows. Payment runs, payroll, receipts expected, debt service, deal maturities.
3. Agent, depth 3 once certified: writes forecast and position entries. Expected flows for today and the next few days, tagged by source. These are internal estimates that change nothing outside and can be overwritten.
4. Agent, depth 2: proposes funding moves. Sweeps, intercompany funding, drawing on a facility or placing a deposit, each with the reason and the cut-off.
5. Agent, refused: entering or confirming deals. Deals commit you to a counterparty.
6. Agent, refused: initiating or approving payments and transfers. These go through the system's payment module with people's authorisations.
7. Person, treasurer: decides on proposals and executes through normal channels.

How do you scope the system role?

Most treasury systems let you separate forecast entry, deal entry, deal confirmation, payment initiation and payment approval as distinct rights. Grant the first, and check the others are absent by testing, not by reading the role name. A role called "cash analyst" in one implementation can initiate payments in another.

Bank connectivity credentials stay out of the agent's reach entirely. The agent reads what the treasury system has already received; it does not log in to bank portals or hold tokens. If statements are late, it reports them late. It does not fetch them by another route.

Some entries need a source class. A balance from a bank statement is signed by the bank. An expected receipt from the receivables ledger is your own sealed data. A customer's emailed promise to pay is declared or external. Tag each forecast entry so the treasurer can see which part of the position rests on a promise.

How do held proposals, revocation and the record work?

Every funding proposal is held. It shows the account, the amount, the reason, the cut-off and the position before and after. The treasurer accepts, amends or rejects it, then executes through the normal channel. The agent records the decision but does not act on it.

Revocation is per capability. Treasury operations can stop the agent writing forecast entries while keeping its read access, for example during a system migration. A certification run that clears no depth drops the agent to depth 1 the same day, and the team prepares entries by hand until it is re-certified.

The filed record holds each entry the agent wrote, its source, the time and any later overwrite by a person, which lets you compare forecast entries against what actually happened.

Which controls matter, and what evidence does each leave?

Statement completeness. Before building the position, the agent confirms a statement arrived for every account. Evidence: an account checklist with missing statements flagged.

Opening balance check. Today's opening ledger balance must equal yesterday's closing. Evidence: a break report.

Ledger versus available balance. The agent records both and uses available balance for funding proposals. Evidence: both values on the position.

Proposals never executed by the agent. Evidence: held verdicts with the treasurer's decision.

What should you measure?

• Forecast entries against actual flows by the end of the day, by source.
• Accounts missing statements at the time the position is due.
• Proposals accepted, amended and rejected.
• Overdraft charges and idle balances, the costs a better position should reduce.
• Time the position is ready each morning.

Where does it usually go wrong?

The role was too wide. Testing showed later that the agent's role could release a payment already initiated. Test every right you did not mean to grant.

Intraday data treated as final. Intraday statements change. The agent should mark them as such and refresh, not lock them into the position.

Forecast entries never cleared. Yesterday's expected receipt that did not arrive is left in, inflating today. Expected flows must roll forward or be closed. Questions about whether an agent can manage daily cash positioning usually start here.