A treasury management checklist for implementation lists what must be true, and signed by a named person, before a business client's treasury service is turned on: the agreement and each product schedule, business due diligence and beneficial ownership, an approved setup, an approved ACH exposure limit, a security procedure accepted in writing, a passing test file, a second person's check of entitlements and limits, and the client's sign-off with the records kept. The difficulty is not writing the list; it is that implementation teams work to a date, and a date-driven go-live tempts people to sign the last items on the morning they are needed. Botminds' Treasury Management Onboarding treats each line as evidence with a signer, and its go-live checklist refuses to turn a service on while any line is open.
The examples follow one fictional sample client, Halvorsen Freight Systems, through the solution at a fictional bank. The rules are linked where they apply; where an item is bank policy rather than law, the page says so.
The treasury management implementation checklist: eight sign-offs
- The agreement and a signed schedule for every service ordered
The schedule is where permitted entry classes, cut-offs and approval limits live. No schedule, no setup.
- Business due diligence and beneficial ownership complete
31 CFR 1010.230 for a new account, or the client's recorded confirmation under FinCEN's February 2026 relief.
- The setup approved against the signed schedules
By the implementation manager, before anything is configured, with every value traceable to a signed page.
- An approved ACH exposure limit, with its first review date
Set by credit before the first entry is initiated, as the OCC expects; debit and credit limits separately.
- A security procedure accepted in writing
And, where the client refused a stronger one the bank offered, that refusal in writing too.
- A passing test for every file and deposit the client will send
ACH file, positive pay issue file, wire template, test deposit: each against the format and the schedule.
- A second person's check of users, entitlements, limits and security procedures
By someone who did not configure them, against the forms the client signed.
- The client's sign-off, and the evidence kept together
Services, limits and cut-offs confirmed by the client; the file retained for the periods the BSA rules set.
What has to be true before a treasury service goes live?
Before a treasury service goes live, every item that applies to that service must be signed, and not every item applies to every service. A positive pay service has no exposure limit; ACH origination has one by rule. A wire service needs a security procedure under Article 4A; remote deposit capture needs a suitability decision under the FFIEC's 2009 guidance. The checklist is therefore per service, and a client ordering four services can have some live while others wait.
Which sign-offs each service needs
| Service | Exposure limit | Security procedure in writing | Test before go-live | Extra item |
|---|---|---|---|---|
| ACH origination | Yes: credit and debit, before the first entry | Bank practice, for file upload and approval | A test file against format and schedule | Prenotes to new receivers, where the schedule requires them |
| Domestic wires | Bank policy: a daily wire limit | Yes: Article 4A governs the payment orders | A test template and approval flow | Dual control offered, or refused in writing |
| Positive pay | No | For the decisioning portal's users | A test issue file in the agreed layout | The default decision, pay or return, in the schedule |
| Remote deposit capture | Deposit limits, bank policy | For the capture application's users | A test deposit | A recorded suitability decision |
The sample client ordered all four. ACH origination and wires were held until a refreshed ownership certification for a 26% entity owner arrived and a person released the hold; under the sample bank's policy the earlier certification, dated April 2023, was too old to rely on. Positive pay and deposit capture were waiting only on their test files. That is what a per-service checklist buys: the bank can say exactly which service is held, by what, and who can release it.
Who signs off a treasury implementation?
A treasury implementation is signed off by several people, each for one thing, and the person who configured the setup signs none of the approvals. That separation is the point of the checklist. A single "implementation complete" signature from the specialist who did the work proves only that the work was done, not that anyone checked it.
Who signs each line, and who may not
| Sign-off | Signed by | May not be signed by |
|---|---|---|
| Agreement and schedules | The client's authorized signer; the treasury officer | Anyone without the client's signing authority |
| Due diligence and beneficial ownership | KYC operations; a person releases any hold | An agent, or the implementation specialist |
| Setup approved | Implementation manager | The specialist who drafted it |
| Exposure limit | Treasury credit officer, above a set amount the head of treasury management as well | Anyone in ACH operations or implementation |
| Security procedure | The client, in writing | The bank alone: it is "established by agreement" |
| Tests passed | Implementation specialist, from the file results | The client, on the bank's behalf |
| Second check | A second implementer | Whoever configured the setup |
| Go-live | Implementation manager, after the client's sign-off | An agent; anyone while a line is open |
The credit line is the one most exposed to deadline pressure. The OCC's ACH guidance puts the limit and its internal approval before the first entry is initiated, not after (OCC Bulletin 2006-39), and the examiners' procedures look for credit monitoring that is independent of ACH operations. An implementation team that turns ACH on with the limit "to follow" has gone live on a service its own credit policy has not approved.
Does a client need to test before go-live?
Yes, in practice, though the requirement usually comes from the bank's own service terms rather than a regulation. The reasons are rule-based all the same. A bank that originates entries for a client warrants them to the rest of the ACH network, so a first live file that is malformed or miscoded is the bank's problem before it is the client's. A test file shows whether the client's own accounting or payroll system produces what the schedule says it will.
Two details make a test meaningful. First, it should be tested twice: against the Nacha format, and against this client's setup, the agreed company ID, the permitted entry classes, the cut-off and the limit. A file can pass the first and fail the second, as a vendor batch coded PPD does. Second, the test should come from the system that will send the live file, not from a template the bank built. Nacha's developer guide also recommends that prenotes "are sent at least three business days prior to initiating a live authorized Entry" (Nacha, ACH Guide for Developers), so a client that needs prenotes cannot test on Thursday and go live on Friday.
The security procedure, accepted in writing
The security procedure is the checklist item with the most legal weight, because under Article 4A it decides who bears the loss on an unauthorized payment order. A security procedure is a method the client and the bank agree on for verifying that a payment order is the client's, and it may use codes, identifying words or numbers, encryption or callbacks (UCC § 4A-201). The same section adds a line every implementation team should know: matching a signature against the specimen on file is not, by itself, a security procedure. The commercially reasonable security procedure test quotes the section and shows how courts read it.
Where the client chooses a weaker procedure than the one the bank offered, the paperwork matters twice over. A procedure the customer chose after refusing a reasonable one is deemed commercially reasonable only if the customer also agreed in writing to be bound by any order, authorized or not, that the bank accepted in compliance with the procedure it chose (UCC § 4A-202(c)). If dual control was offered and declined, the signed refusal belongs on the checklist beside the signed acceptance. The ACH origination agreement template shows the clause, and the court case that tested it.
The FFIEC's 2021 authentication guidance names the business-customer controls a bank should make available, including a setting that makes certain transactions need a second employee's approval (FFIEC, 2021; a corporate account takeover policy quotes the list). The checklist does not require a client to use them. It requires the bank to have offered them and to hold the client's answer in writing.
Beneficial ownership after the 2026 relief
Beneficial ownership must be complete before a service that moves money goes live, but since February 2026 "complete" can mean a recorded confirmation rather than a fresh collection. The CDD rule requires a bank to identify and verify the beneficial owners of a legal entity customer whenever it opens a new account (31 CFR 1010.230(b)). FinCEN's exceptive relief order of February 13, 2026 grants relief from doing so at each new account, provided the customer confirms the earlier information, and states that "The covered financial institution must also maintain a record of the certification or confirmation the customer provided" (FinCEN, FIN-2026-R001).
Two consequences for the checklist. If treasury services open new accounts, the line is closed either by fresh identification and verification or by the client's recorded confirmation. And a bank may still decide, as the sample bank did for a certification dated 2023, that its own policy calls for a refresh; that is a policy choice, not a requirement of the order. The guide to the beneficial ownership certification covers the form itself.
Date-driven and evidence-driven go-lives
The difference between a checklist that protects the bank and one that decorates a project plan is whether the date waits for the evidence or the evidence is gathered to meet the date.
The same checklist, run two ways
Date-driven: A date agreed with the client at the signing meeting.
Evidence-driven: The last signed line. The date is a forecast until then.
Date-driven: Requested in week two; "approved to follow" on go-live morning.
Evidence-driven: Approved before the first entry, with the first review date set at once.
Date-driven: Assumed accepted because the agreement was signed.
Evidence-driven: Acceptance, and any refusal of dual control, signed and kept with the file.
Date-driven: The configuring specialist re-reads their own work.
Evidence-driven: A second implementer checks against the signed forms; the system refuses the configurer's signature.
Date-driven: Go-live proceeds with an exception noted.
Evidence-driven: That service waits; services with every line signed go live.
Records the examiner will ask for
The checklist doubles as the record of the implementation, and the retention clocks differ by item. For beneficial ownership, the CDD rule keeps identification records for five years after the account closes and verification records for five years after they are made (31 CFR 1010.230(i); the corporate KYC documents list sets out each clock). The general BSA rule is five years for any record it requires (31 CFR 1010.430(d); BSA record retention quotes it). Agreements, schedules and the signed security procedure are contracts, kept for as long as the bank's legal hold policy says.
What an examiner or internal auditor wants is less the documents than the chain: which schedule a setting came from, who approved the setup, why the limit is the number it is, who checked the entitlements and when. A checklist whose lines link to that chain answers in minutes. One that holds only ticks answers in days, if at all.
How Treasury Management Onboarding enforces the order
In the solution, every line of the go-live checklist is a signed item with a name, a time and a reason, and the go-live button cannot be pressed while one is open. The sample client's lines landed unevenly: the agreement, schedules, setup approval and the client's acceptance of the security procedures on day 1, and four more on day 6, the day the hold was released, the limit approved, the corrected test file passed and the second check signed.
Half the sign-offs landed on one day: the day the blockers cleared
The go-live checklist, with a signer and a date on every line
The audit trail behind those lines is not editable, by people or agents. It records each agent's work, such as the test files read overnight and the messages drafted, beside each person's approvals, so an auditor can see what the agents proposed and what a person decided.
Who did what, when, why, and on which evidence
For deposit capture, the extra line is the suitability decision the FFIEC asks banks to base on "appropriate risk-based guidelines" (FFIEC, Risk Management of Remote Deposit Capture); which clients qualify for remote deposit capture turns that guidance into criteria. To see the checklist working on an implementation, start from Treasury Management Onboarding.
Questions people ask
What is a cash management implementation guide?
It is a bank's written procedure for setting up a business client's treasury services: the documents to collect, the systems to configure, the tests to run and the approvals needed before go-live. A good one is organized as signed evidence per service, not as a project timeline, so it still holds when a service is held and others go live.
What records should a treasury implementation keep?
The signed agreement and schedules, the due diligence and beneficial ownership file, the approved setup with its sources, the exposure limit and its reason, the security procedure accepted in writing, test results, the second check and the client's sign-off. Beneficial ownership identification records are kept five years after the account closes under 31 CFR 1010.230(i).
Can a treasury service go live before the exposure limit is approved?
Not for ACH origination. The OCC expects banks to set limits and obtain internal approvals before allowing ACH transactions to be initiated, and examiners check that limits exist and are reviewed. Services without an exposure limit, such as positive pay, can go live on their own lines; for positive pay those lines include the client's agreed cut-off and default decision, set out in the positive pay deadline and default decision.
Does a treasury client need to accept the security procedure in writing?
Article 4A defines a security procedure as one established by agreement, so the client must agree to it. Writing becomes decisive when the client refuses a reasonable procedure the bank offered: the chosen one is deemed commercially reasonable only if the client expressly agreed in writing to be bound by orders accepted under it.
Who confirms go-live in a treasury implementation?
Usually the implementation manager, after the client's sign-off and once every other line is signed. In Treasury Management Onboarding no agent can turn a service on, and the confirm step stays disabled while any prerequisite is open.