AI treasury management software at a bank is software whose agents do part of the work of setting up and servicing business clients' treasury services, and the question that decides whether it is safe is what an agent may set up on its own. The answer under today's rules: agents may read, check and draft; named people must approve setups, decide exposure limits, certify nothing on the client's behalf, send nothing to a client and turn nothing on. That line is the bank's to draw, because the interagency model risk guidance issued on April 17, 2026 leaves generative and agentic AI models outside its scope. Botminds' Treasury Management Onboarding is built on that line: seven agents draft and explain, and four named people decide.
The examples follow a fictional sample bank and client in the solution. Regulatory sources are linked where they appear.
Two kinds of AI treasury management software
Two quite different products answer to "AI treasury management software". One is for a company's treasurer: software that forecasts cash, manages positions and initiates payments from the company's own accounts. The other is for the bank that provides those accounts and services: software that helps the bank's implementation and service teams set clients up and keep them running. This guide is about the second.
The distinction matters because the risks sit in different places. A corporate tool acts for one company with its own money. A bank-side agent touches the configuration that governs many clients' payments: who may initiate a wire, how much ACH credit a client has, which company ID a file must carry. An error there is the bank's, under rules written for banks.
Does the 2026 model risk guidance cover AI agents at a bank?
No. The revised interagency guidance on model risk management, issued by the OCC, the Federal Reserve and the FDIC on April 17, 2026, expressly excludes generative and agentic AI as too new and fast-moving for it, and the agencies have said they will ask about AI separately (OCC Bulletin 2026-13). The exact words, and how a bank sorts its tools against them, are in is a customer risk rating a model.
The new guidance replaced the framework banks' model programs grew up around, the 2011 letter SR 11-7 and the 2021 statement SR 21-8 (SR 26-2). It describes itself as setting no enforceable standards or prescriptive requirements, and as aimed chiefly at banks with more than $30 billion in assets. The agencies promised a request for information on model risk management that would look in particular at banks' use of AI, generative and agentic included (OCC Bulletin 2026-13). The Federal Reserve's Vice Chair for Supervision described the change as amending the guidance "to clarify that it does not apply to generative or agentic AI" (Bowman, May 1, 2026).
Out of scope does not mean unsupervised. It means the controls that govern an agent are the ones that already govern the work it does: the credit policy for exposure limits, Article 4A for security procedures, the CDD rule for beneficial ownership, the bank's access controls for anything that touches its systems.
Is AI allowed in bank onboarding?
Yes. No federal rule prohibits banks from using AI in onboarding, and the regulators supervise it through the rules that already apply to the work. The GAO's 2025 review of AI in financial services found that federal financial regulators oversee AI mainly through the laws, guidance and risk-based examinations they already have (GAO-25-107197; AI audit software for branch reviews quotes the finding).
The OCC's own view of practice this year matches the line this guide draws:
"Banks are taking a measured approach to the adoption of generative AI (genAI) and agentic AI, with usage generally limited to specific use cases with guardrails and human-in-the-loop accountability to manage risk."
OCC, Semiannual Risk Perspective, Spring 2026
Treasury onboarding is a good fit for that pattern: the use case is specific, the guardrails can be written down, and every decision already has a named owner.
Where agents earn their place in treasury onboarding
Agents earn their place in the parts of treasury onboarding that are reading and writing rather than deciding: turning signed schedules into setup fields, turning a failed 94-character file into an explanation, turning statements into an exposure request. Those steps take most of an implementation's elapsed time and carry little judgement, which is exactly the profile of the "specific use cases with guardrails" the OCC describes.
The sample desk shows the scale. Overnight, the agents read 37 client test files, of which 14 failed, and drafted 9 messages to clients and 4 new setups, so that the eleven implementations needing a person that day were ready to decide when the team arrived. On the sample client, the first test file was read at 6:40 AM; a specialist sent the drafted fix at 10:38; the corrected file passed at 11:52. Each of those people-facing steps, the send, the approval of the limit at 10:31, the release of the ownership hold at 10:26, was a person's.
The pattern generalizes into a simple test for any proposed use: if the output of a step is a draft that a named person will read before it has any effect, an agent can do it; if the output takes effect by itself, a person should. The implementation specialist's guide follows the same day from the person's side.
What can AI not do in treasury onboarding?
In treasury onboarding, an agent should not make any decision the law, the rules or the bank's credit policy assign to a person or to the client. Four stand out, each for a different reason.
Choose the client's security procedure. Under Article 4A, whether a security procedure is commercially reasonable turns on what the client asked for, what the bank knew of its circumstances, and the size, type and frequency of the payments it normally sends (UCC § 4A-202(c); bank liability for wire fraud quotes the factors in full). An agent can record what was offered and what the client chose; the choice and its written acceptance are the client's.
Set or raise an exposure limit. Nacha's rules require the bank to set, apply and periodically review an exposure limit for each originator (Nacha, 2025; how to calculate an ACH exposure limit), and examiners expect the decision from credit, independent of operations. An agent can assemble the request; a credit officer decides.
Certify ownership or release a hold. The CDD rule's certification comes from the person opening the account on the client's behalf (31 CFR 1010.230); the bank verifies it. An agent can compare documents and say what is missing; a person releases the hold. Act on the client's behalf. An agent should never change the client's file, send it to the network or send the client a message on its own; the client's systems and the bank's people do those.
The may and may-not matrix
Written as a matrix, the line becomes something a model risk or operational risk team can review and an auditor can test.
What an agent may and may not do in a treasury implementation
| Task | An agent may | An agent may not | Who decides |
|---|---|---|---|
| Setup | Draft every field from the signed schedules, citing its page; hold uncertain values | Write a live configuration or change a signed term | Implementation manager approves; a specialist applies |
| Due diligence | Assemble verification and ownership from the bank's systems; name what is missing or stale | Certify ownership; release a hold | KYC operations; a named person releases |
| Exposure limit | Measure what the client will originate and propose limits with the arithmetic shown | Set a limit or raise one after approval | Treasury credit officer, with a reason code |
| Test files | Check every file against the format and the client's setup; place each error on its record | Change the client's file; send any file to the network | Implementation specialist reviews |
| Client messages | Draft the fix in the controller's words | Send without a named person's approval | Implementation specialist sends, under their name |
| Entitlements | Show each configured value beside the form it came from | Sign the second check | A second implementer who did not configure it |
| Go-live | Assemble the checklist and the evidence file | Turn a service on | Implementation manager confirms |
The seven agents of Treasury Management Onboarding, and what each never does
Agent
Implementation coordinatorRuns one client's implementation as one unit of work: the other agents in order, the day clock, the go-live checklist.
Never: approves a step or turns a service on
Agent
Setup agentDrafts every setup field from the signed proposal and schedules, citing each page.
Never: writes a live configuration or changes a signed term
Agent
Due Diligence agentRefreshes business verification and beneficial ownership from the bank's systems and names what is missing.
Never: certifies ownership or releases a hold
Agent
Limits agentAssembles the exposure request from what the client will actually send, with the arithmetic shown.
Never: sets a limit or raises one after approval
Agent
File agentValidates every test file against the Nacha format and the client's setup; writes each error beside its record.
Never: changes a client's file or sends one to the network
Agent
Client agentWrites the controller exactly what to fix, in a controller's words.
Never: sends without a named person's approval
Agent
Evidence agentAssembles the evidence file: schedules, setup sources, approvals, the second check, the sign-off.
Never: writes to a client record
A person decides
Four named peopleThe implementation manager approves and confirms go-live; the credit officer decides limits; a second implementer checks; the specialist sends.
Who approves an AI-drafted setup?
The implementation manager approves an AI-drafted setup, against the signed schedules, before anything is configured; a second implementer then checks what was configured. The agents' drafting does not shorten that chain. It changes what the approver looks at: every value beside the signed line it came from, with the uncertain ones already set aside.
One sample setup, and how much of it a person had to read
87fields
drafted across four services and two systems, each citing its source
26fields
flagged for a person's eye by design
3fields
held because confidence fell below the 0.90 floor
1right
removed by the second implementer: from the template, not the client
The confidence floor deserves its own line in the bank's policy. It is the point below which an agent's draft is not shown as a value at all but held for a person to read, and it should be set, versioned and changed like any other risk threshold. In the sample, three fields fell below it; each was read by a person before the setup went to approval.
Testing an agent before it touches a client
Because the model risk guidance no longer prescribes how to validate generative or agentic AI, the bank has to decide what evidence it wants before an agent works on a live implementation. The work itself suggests the tests. Run the Setup agent on closed implementations and compare its drafts with what the bank's implementers configured. Run the File agent on past client test files whose failures are already known, including files with errors planted on purpose, and count what it finds, misses and wrongly flags. Read the Client agent's drafts against the messages specialists actually sent.
Two rules keep such a test honest. The bank picks the files and keeps the answers from the vendor. And every miss is read and explained, not only counted, because in onboarding one missed company ID matters more than many correctly spotted padding errors. After go-live, the same comparison continues: the audit trail records what each agent drafted and what a person changed.
People and agents on one audit trail, none of it editable
What to ask a vendor of AI treasury management software
Questions for any vendor of AI for bank treasury operations
- Show the may-not list for each agent
In the product, not in a slide. Ask what happens when a user tries to make the agent cross it.
- Show the source behind every drafted value
A value an approver cannot trace to a signed page has to be re-checked from scratch.
- Where is the confidence floor, and who sets it?
It should be the bank's setting, versioned, with held values visible.
- What do the agents write, and where?
Drafts in the vendor's system are fine. Live configuration should be written only after a named approval, and only to the bank's own systems.
- How do you test on our files?
Closed implementations and past test files the bank chooses, scored by the bank's implementers, with planted errors.
- What does the audit trail show?
Each agent action and each human decision, unalterable, exportable, with reasons.
- What changes when the agencies' AI request for information lands?
A vendor should be able to say how its controls map to whatever the agencies ask.
The limit proposed with its arithmetic, and the decision left to credit
For how the same line runs through the software around the agents, see commercial banking onboarding software; for the File agent's work in detail, what a Nacha file validation tool checks, and what it cannot. The solution is at Treasury Management Onboarding.
Questions people ask
Can AI set up treasury services for a bank's clients?
AI can draft the setup, every field from the signed schedules with its source, and check the client's test files. Approving the setup, applying it to live systems, deciding the exposure limit and turning services on should remain with named people, and in Treasury Management Onboarding the agents cannot do those things.
Does SR 11-7 still apply to AI models?
SR 11-7 was superseded on April 17, 2026 by SR 26-2, the revised interagency guidance on model risk management. The revised guidance expressly leaves generative and agentic AI outside its scope, pending a request for information the agencies have said they plan to issue.
Who is accountable when an AI agent drafts a wrong setup?
The bank, through the people who approved and checked it. That is why the approval and the second check should show each drafted value beside its source, and why the audit trail should record both what the agent drafted and what the person decided.
What is AI in treasury management used for at banks today?
The OCC reported in spring 2026 that banks are adopting generative and agentic AI cautiously, for specific use cases with guardrails and human-in-the-loop accountability, mostly productivity and customer experience tools. Drafting setups and explaining test files are productivity uses of that kind.
Should an AI agent ever change a client's payment file?
No. A file the bank changed was not produced by the client's system, so the next live file fails the same way, and the bank has sent content its client never approved. The agent should say what to change and where; the client fixes its own system.