Treasury management onboarding that takes a client from a signed proposal to live services, every setup checked
Live in days, not a month, with every setup signed and checked.
See one case, screen by screen ↓Treasury management onboarding is the work a bank's implementation team does between a signed treasury proposal and the client's first live payment: due diligence and beneficial ownership, a product schedule for each service, an ACH exposure limit, users, entitlements, limits and cut-offs in the digital banking platform and the payments hub, a security procedure the client accepts in writing, and the client's own test files. Botminds puts seven agents in front of that work — drafting every setup field from the signed schedules, proposing the exposure limit, and explaining each failed test file in plain words — while a named person approves the setup, decides the limit, checks the entitlements and turns the services on.
AI use cases in banking: a buyer's guide to agentic AI for bank and credit union operations →
Updated
Treasury management onboarding is the work between a signed proposal and a business client's first live payment: opening or linking the accounts, business due diligence and beneficial ownership, a product schedule for each service, an ACH exposure limit from treasury credit, users and entitlements in the digital banking platform, formats, limits and cut-offs in the payments hub, a security procedure the client accepts in writing — and the client's own test files. None of it is billed until the service is turned on.
Two things make it slow. The setup is re-keyed out of signed PDFs into two systems, so a wrong cut-off or a missing entitlement is found weeks later by the client. And the test file is the stall: the client's accounting system produces a file, the bank rejects it, and a specialist reads 94-character records to work out why, writes an email in bank vocabulary, and waits. The causes repeat — a Company ID left behind by a previous bank, vendor payments coded for consumer accounts — and each round trip costs a day or more.
Estimated split of one four-service implementation, by hand and with the agents; the 'after' column totals the nine days the working solution's hero client takes, against a 31-day average at the same bank — our arithmetic, kept modest.
Seven agents draft the setup from the signed schedules, propose the exposure limit and explain every test file; a manager approves, a credit officer decides and a second implementer checks.
Halvorsen Freight Systems signed on a Thursday and ordered four services: ACH origination, positive pay, domestic wires and remote deposit capture. Here is what happens to the implementation, screen by screen, in the working solution.
The agents read the signed proposal and the four product schedules and draft 87 fields across the digital banking platform and the payments hub — accounts, limits, cut-offs, file formats, entitlement groups and security procedures — each one carrying the schedule and page it came from.
26 of the 87 fields need a person's eye; the rest are formats the schedule fixes.
Opening any drafted value shows the signed line behind it — "Permitted Standard Entry Class codes: PPD (consumer), CCD (corporate)" on page 2 of the ACH Origination Schedule — beside the value the agents drafted.
The certification for a 26% entity owner was signed in April 2023. The refreshed one arrives at 8:05 AM and names both of its natural-person owners, neither reaching 25% of the client — and a person, never an agent, releases the hold.
212 payments for $412,860.00 in two batches. The Company ID in the file is 1742900183 where the origination agreement says 1000045512, and 38 vendor payments worth $146,450.00 are coded PPD where a business account takes CCD. Eight other checks pass.
The file is checked twice: against the Nacha format, and against what this client actually agreed to.
The file header, both batch headers and the first vendor entry, shown as the client's own system sent them, with the Company ID marked in three places and the entry class on the vendor batch in one. Clicking a field says what it is and which positions it occupies.
Not "field 3 mismatch", but: open the ACH profile in your accounting system and change the Company ID to 1000045512; code the vendor batch CCD and send the file again, nothing else in it changes. One button sends it, and a person's name goes on it.
The same 212 payments for the same $412,860.00, with the Company ID corrected and batch 2 coded CCD. Both errors gone, nothing else changed, and ACH origination is ready for go-live.
They asked for $1,200,000 of daily credit. The agents measured a $266,410.00 payroll and a $146,450.00 vendor run — $412,860.00 if both land on one day — and proposed $900,000, 2.2 times that peak. Approved at $900,000 with a reason, and the Nacha review dates set at the same moment.
First review January 11, 2027, then annually — a date, not a diary note.
Devin configured this implementation, so the system refuses his signature on its check. Noor checks 14 users, 31 entitlements, 4 limits and 3 security procedures against the form the client signed, and removes one entitlement that came from the template rather than from the client.
The agreement and four schedules, the approved setup, current beneficial ownership, the approved limit with its review dates, the passed test file, the second check and the security procedures accepted in writing. Only then can a person confirm Friday, October 16 — day 9, against a 31-day average.
Seventeen entries on the trail, none of which can be edited: the agents reading 37 overnight test files, the ownership certification, the limit and its reason, the hold released, the message sent to the client by a named person, the entitlement removed and the check signed.
The same implementation, seen by the four people who carry it — what their day looked like, and what it looks like now.
Seven agents draft the setup from the signed schedules, propose the exposure limit and explain every test file; a manager approves, a credit officer decides and a second implementer checks.
Treats one client's implementation as one unit of work: runs the other agents in order, keeps the day clock and the service level, and assembles the go-live checklist.
Reads the signed proposal and each product schedule and drafts every setup field for the services ordered, citing the schedule and page beside each one.
Refreshes business verification and beneficial ownership for a legal entity customer (31 CFR 1010.230) from the core banking system, the client record and document imaging, and names what is missing or out of date.
Assembles the ACH exposure request — the payroll and vendor runs the client will actually send, their account history, audited financials and return record — and proposes a daily credit and debit limit with the arithmetic shown.
Validates every client test file against the Nacha format and against that client's own setup — the agreed Company ID, the permitted entry classes, transaction codes, dates, prenotes and both control totals — and writes each error beside the exact record.
Writes the client's controller exactly what to fix: the error, the record it sits on, what to change it to and what happens next, in the words a controller uses.
Assembles the implementation evidence pack: the signed schedules, every setup field and its source, each approval and its reason, the second check, the security procedures and the client's sign-off.
Approves the setup; a second implementer checks before go-live. The agents propose; a named person decides.
13 screens from the working solution, on its sample data. Pick one to see it large.
The thresholds, clocks and templates every implementation is held to are settings, versioned and on the audit trail.
| Setting | Default | Choose from |
|---|---|---|
| Who approves a drafted setup | The implementation manager | One named approval before anything is configured |
| Who approves an ACH exposure limit | The treasury credit officer | Above a set amount, the head of treasury management as well |
| Second check before go-live | Always on | Never the person who configured it |
| Target days to live | 10 days | Escalate on day 20, and to the head of treasury on day 30 |
| Test file required before go-live | On, per service | Set per service template |
| Retention | 5 years after the relationship ends | Redaction on export; account numbers masked |
| Agent confidence floor | 0.90 | Below it, a person reads the drafted value |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
Sources: Nacha Operating Rules — ODFI risk management, exposure limits and their review, and the fraud monitoring rules effective March 20, 2026 (phase 1) and June 19, 2026 (phase 2) · FinCEN CDD Rule, 31 CFR 1010.230 (beneficial ownership for a legal entity customer) · UCC Article 4A (the security procedure a client accepts in writing) · FFIEC, Risk Management of Remote Deposit Capture, January 14, 2009 · DeNovo Treasury on commercial onboarding friction (20–25% of poorly onboarded relationships reduce usage or leave within 18 months) · "target" = design goal, measured in the pilot · "demo" = seen in the working solution, on its sample data · "typical" = published figures · "estimated" = our arithmetic from published inputs. Corvane National Bank, Halvorsen Freight Systems and the people named on this page are fictional — characters and sample data in the working solution.
Treasury management onboarding is the work a bank's implementation team does between a signed treasury proposal and the client's first live payment: due diligence and beneficial ownership, a product schedule for each service, an ACH exposure limit, users, entitlements, limits and cut-offs in the digital banking platform and the payments hub, a security procedure the client accepts in writing, and the client's own test files. Botminds puts seven agents in front of that work — drafting every setup field from the signed schedules, proposing the exposure limit, and explaining each failed test file in plain words — while a named person approves the setup, decides the limit, checks the entitlements and turns the services on.
At the bank in the working solution, the 2025 cohort averaged 31 days from a signed proposal to the first live file. The design goal is to be live in days rather than a month: the hero client orders four services and goes live on day 9, which is where the "22 days of fee income earned earlier" figure comes from. Every number on this page is tagged, and the targets are to be measured in your own pilot.
Usually for dull, repeated reasons. The two in the working solution are the common ones: the Company Identification in the batch header is the identifier left behind by a previous bank rather than the one on the origination agreement, and payments to suppliers' business accounts are coded PPD when a corporate credit takes CCD. The File agent checks the file against the Nacha format and against this client's own setup, then writes each error beside the exact record and the character positions it occupies.
PPD is the Standard Entry Class code for a payment into a person's own account — payroll to an employee. CCD is the class for a corporate credit or debit, which is what a payment to a supplier's business account is. A client's schedule says which classes the bank permits them to originate, and the agents check each batch against that, not only against the file format.
The bank does, as the originating institution: the Nacha rules require it to assess each originator and to set, monitor and review an exposure limit, and since March 2026 to run risk-based processes to identify entries initiated in fraud, reviewed at least once a year. Here the Limits agent assembles the case and proposes an amount with the arithmetic shown; the treasury credit officer decides with a reason code, and the first and annual review dates are created as the limit is approved.
The signed agreement and the product schedule for that service; current beneficial ownership for a legal entity customer; an approved exposure limit where the service needs one; a passed test file; a second implementer's check of every user, entitlement, limit and security procedure; the security procedures accepted in writing; and the client's own sign-off. The checklist refuses go-live while any of those is open, and no agent can turn a service on.
No. The agents read, check and draft. No agent changes a client's file, sends one to the network, writes a live configuration, sets or raises a limit, certifies ownership, releases a hold, or sends a client a message. Below the confidence floor, a drafted value is held for a person to read.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your treasury services agreement and schedules, your service templates and a sample of past client test files — and it goes live once every quality gate has passed. We will walk you through it on your own implementations first.
Every exception decided by a named person before the cutoff, not left to the default.
1-min demoAccount Analysis Fee Leakage ReviewEvery analyzed relationship compared with its signed schedule, every month.
1-min demoTreasury Management Client ServicesEvery user, limit and entitlement change verified before it is made, by two people.
1-min demoWe'll run Treasury Management Onboarding on a sample of your own signed schedules and client test files.