Treasury management client services where every change is verified before it is made
Every user, limit and entitlement change verified before it is made, by two people.
See one case, screen by screen ↓Treasury management client services is the team inside a bank or credit union that handles maintenance for business clients already live on cash management: adding and removing users, changing entitlements and approval limits, adding services, and changing the contacts the bank calls to verify things. It is a separate queue from onboarding, and it is far larger — maintenance requests outnumber new setups many times over.
AI use cases in banking: a buyer's guide to agentic AI for bank and credit union operations →
Updated
Treasury management client services is maintenance work, and maintenance outnumbers new setups many times over. Add a user, remove the controller who left, raise an ACH approval limit, add wire release, change the callback number, add positive pay. Each one changes who may move a business client's money, and each one arrives as an email, a secure message, a signed form or a walk-in that somebody has to believe. The agreement says who may ask for a change; nobody opens it at eight on a Tuesday. The specialist recognizes the name, recognizes the signature block, and makes the change.
That is the gap. A lookalike domain, an urgent tone and a plausible name is all a business email compromise needs, and asking for a new user with wire release is quieter than asking for a wire — it keeps paying out for weeks. Callbacks are inconsistent: some specialists call, some reply to the message, some call the number in the signature block, which is the attacker's number. Limits creep, because the approval limit lives in one system and the approved exposure limit and its review date live in another. And when internal audit or the examiner asks what happened on a change made in March, the answer is a forwarded message, a screenshot and a memory.
Estimated split for a single maintenance request, by hand and with the solution. The callback row is elapsed time, not work.
Seven agents read the request, the agreement and the limits; a specialist makes the change and a second approves it.
At 08:14 on a Tuesday an email asks a credit union's business services team to add a user with wire release up to $250,000 and raise an ACH approval limit from $150,000 to $400,000. It names the client's controller. Here is what happens next, screen by screen, in the working solution.
The agents read the message and write what is actually being asked: add Dana Whitfield as a user with wire release up to $250,000, and raise the ACH approval limit from $150,000 to $400,000, for Ashgrove Millwork LLC. The message as it arrived is one click away, kept unchanged. The specialist does not have to read a thread to know what is on the table.
“Agents read, check and cite. They never make a change and never decide.”
Beneath the sentence sit five links. Who asked — checked: the request names Marguerite Ellis, Controller, an authorized administrator on file since March 4, 2021. Did it come from her — broken. May she ask for this — needs a person. The callback to the number on file — broken. Does it fit the limits — broken. One decision bar sits at the bottom, and nothing above it is a verdict.
“A broken link means no change is made.”
Clicking the source on a broken link shows §7.2 of this client's own cash management agreement: the credit union acts on a maintenance instruction only through the secure message center, from the electronic mail address of an authorized administrator recorded with the credit union, on a signed Service Change Form, or in person at a branch. The agents did not invent a rule — they read the one the client signed.
The message came from controller@ashgrove-millwork.co. The client's domain on file is ashgrovemillwork.com. The sending domain was registered on October 17, 2026 — three days before the request, against a rule that holds anything under 90 days. The reply-to address differs from the sender, the language is urgent, and nothing has ever arrived from this address before.
Channel allowed? No — the agreement allows an administrator's address on file, or the secure message center.
Two numbers sit side by side: (812) 555-0147, the contact on file since March 4, 2021, and (502) 555-0188, given in the request itself and marked never to call. Alina calls the number on file, works through the script the agent drafted, and records the outcome: the controller did not send it and has asked for no change.
“I did not send that. Please call me, not whoever emailed you.”
Alina refuses the request. The reason code — RF-03, suspected business email compromise — is proposed by the agents from what they found, and she can change it. Her note records that the client was reached on the number on file. The panel says plainly that this is kept with her name, the time and the evidence the agents cited, and cannot be edited afterwards.
The refusal waits for a supervisor, beside a routine change waiting for a second specialist. Renata reads the same five links, the reason code and the note before she approves. Approving the refusal opens a fraud referral with the evidence already packed.
“Approving puts your name on this, beside Alina Petrosyan.”
Case FR-2026-0412 opens for the fraud investigator with six pieces of evidence: the message and its headers, the domain registration record, callback CB-88134, the agreement clauses, the entitlements as they stood at 08:14, and the chain with every decision. The lookalike domain goes on a watch list, where two more requests this week were already held for callback.
Dana Whitfield: never created. ACH approval limit: $150,000, unchanged. Wire release ceiling: $100,000, Owen Shaw only.
Most requests are not fraud. REQ-24809 from Kestrel Freight Lines LLC asks to remove a leaving controller and move his ACH approval to the finance director. All five links are checked and the callback was completed at 08:50, so the change drafter has the exact change ready with before and after values. Alina submits it; a second specialist approves it; then it takes effect.
Every action by a person or an agent is written as it happens, sealed daily and kept five years. Each row carries a reason and the evidence behind it — the clause, the message headers, the callback record, the limits of record. An auditor can read everything and export the pack for one request; in that role, approving and sending back are not available at all.
The same request, seen by the four people who carry it — what their morning looked like, and what it looks like now.
Seven agents read the request, the agreement and the limits; a specialist makes the change and a second approves it.
Reads the secure message, email, signed form or branch note and writes the request as one plain sentence: the client, the change and the amounts.
Reads the corporate resolution, the cash management agreement and the entitlements on file, and says whether this requester may ask for this change — citing the clause, down to the countersignature a wire release needs.
Tests how the request arrived against the channels the agreement allows, and looks for business email compromise signs: a lookalike domain, the sending domain's age, a reply-to that differs, urgency language and a first-time sender.
Schedules and scripts verification to the contact on file, records the outcome in the client's own words and attaches the call record to the chain.
Checks the requested limit against the client's approved ACH exposure limit, wire ceiling and remote deposit limit, with the date of the last review and the highest day actually used.
Prepares the exact change for the business digital banking administration — user, entitlements, limits — with before and after values side by side, ready for a specialist to make.
Writes the record as the work happens and assembles the packs for internal audit, the examination and the fraud investigator — the request, the chain, the callback, the decision and the before and after.
Decides, makes, and a second approves. The agents propose; a named person decides.
Ask about a request, a client, a limit or a rule — or say what to change. Every answer points at the clause or record behind it.
Why did this request fail the chain?
It broke on three of five links. The message came from controller@ashgrove-millwork.co, while the client's domain on file is ashgrovemillwork.com and ashgrove-millwork.co was registered on October 17, 2026, three days ago; the agreement allows only an administrator's address on file or the secure message center. The callback to (812) 555-0147, the number on file, reached the controller at 09:02 and she did not send it. And a $400,000 approval limit sits above the approved $350,000 daily exposure limit set on March 12, 2026.
Who can approve a wire release for this client?
Under §4.4 of this client's cash management agreement, a wire release entitlement must be designated by one authorized administrator and countersigned by a second — here Marguerite Ellis, Controller, and Owen Shaw, Owner and Member-Manager. On the bank's side, a payment-release entitlement is approved by the Business Services Supervisor, not by a second specialist.
Show me this client's requests in the last 12 months
Five, all through the secure message center or a signed form, all verified by callback: a view-only user on July 8, a remote deposit limit rise to $75,000 on April 2, the annual originator review on March 12, a user removal on November 19 and a wire template on September 3. This is the first request ever received from an address not on file.
Draft the note back to the client
Drafted, addressed to the controller's address on file and never to the one on the request. It says what was received, that she was called on the number on file, that no change was made to users, entitlements or limits, and asks her to check her own mail rules. It names no case number and no report.
13 screens from the working solution, on its sample data. Pick one to see it large.
What the bank decided, written down — not a habit in someone's head. Every change to a rule is on the trail.
| Setting | Default | Choose from |
|---|---|---|
| A user add with payment release | Always verified by callback | On · off, per change type |
| A limit increase | Callback, and checked against the approved exposure | On · off, per change type |
| A contact or callback change | Verified on the number already held | On · off, per change type |
| A view-only user add | No callback required | On · off, per change type |
| Who we call back | The contact on file only | The contact on file only · the contact on file, then a second administrator |
| Hold a request from a domain newer than | 90 days | 30 · 60 · 90 · 180 days |
| Channels a request may arrive on | Secure message center, an administrator's address on file, signed form, branch visit | Each channel on or off; a telephone call is always held for callback |
| A payment-release entitlement | Approved by the supervisor | Business Services Supervisor · any second specialist |
| Respond within | 4 business hours | 2 · 4 · 8 business hours, complete within 1 or 2 business days |
| Escalate at | 80% of the clock | 60% · 80% · 90% of the clock |
| Records kept for | 5 years | 5 · 7 · 10 years |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
“demo” = seen in the working solution, on its sample data · “target” = the design goal, measured in the live solution · “estimated” = our estimate · “typical” = published figures (FBI Internet Crime Complaint Center, 2025 Internet Crime Report — $3,046,598,558 in reported business email compromise losses; FinCEN analysis of business email compromise in the real estate sector — nearly 88% of incidents sent the first fraudulent transfer to a US depository institution). Rules named as context: the FFIEC's 2021 guidance on authentication and access, the Nacha Operating Rules on originator exposure limits, and UCC Article 4A on security procedures. The credit union, businesses, people, accounts, routing numbers, domains and telephone numbers on this page are fictional — characters and sample data in the working solution.
Treasury management client services is the team inside a bank or credit union that handles maintenance for business clients already live on cash management: adding and removing users, changing entitlements and approval limits, adding services, and changing the contacts the bank calls to verify things. It is a separate queue from onboarding, and it is far larger — maintenance requests outnumber new setups many times over.
It walks five checks on every request and shows them. Who asked, and are they an administrator on file. Did it really come from them, tested against the channels the agreement allows. Does the agreement let them ask for this particular change. What did the callback to the contact on file say. And does the change fit the client's approved limits. Each link is checked or broken and carries the clause or record it relied on.
Whoever the client's own documents say. An agent reads the corporate resolution, the cash management agreement and the entitlements on file, and cites the clause — including where a change needs more than one person, such as a wire release entitlement that one administrator designates and a second countersigns.
It tests the channel before anyone replies: a lookalike domain against the client's domain of record, how old the sending domain is, whether the reply-to differs from the sender, urgency language, and whether anything has ever arrived from that address before. Anything not allowed by the agreement is held, and the callback goes to the contact on file rather than the number in the request.
If the new limit sits above the client's approved exposure limit, it cannot be completed as a maintenance change. The solution compares the request with the limits of record, shows the date of the last review and the highest day actually used, and offers one action: send it to an originator review.
Yes. Every action by a person or an agent is written as it happens with who, what, when, why and which evidence, sealed daily and kept five years. The trail filters by client, actor and date, and one request's whole pack exports in a click. In the auditor role, approving and sending back are not available at all.
Always. The agents read, check and cite; they never make a change and never decide. A specialist decides with a reason code, makes the change in the administration system, and a second specialist approves it before it takes effect. Refusals, overrides and payment-release entitlements go to a supervisor.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your resolutions and cash management agreements, your entitlement model, your approved exposure limits and your approval matrix — and it goes live once every quality gate has passed. The verification rules, channels, clocks and approvers are settings you own from day one.
Every originator measured against all three Nacha levels every day, not once a year.
1-min demoTreasury Management ProposalsA priced proposal in two days, not two weeks, every value cited to a statement line.
1-min demoThird-Party Sender Due DiligenceEvery originator behind the sender screened and measured, not just the sender.
1-min demoWe'll run Treasury Management Client Services on a sample of your own past maintenance requests.