Commercial banking onboarding software for treasury services has to do something account-opening software is not built to do: take a business client whose account is already open and set up its treasury services, ACH origination, positive pay, wires and remote deposit capture, in the digital banking platform and the payments hub the bank already runs, from the schedules the client signed. Account-opening and KYC platforms verify the client and open the account; the treasury implementation that follows needs a credit decision, entitlements, cut-offs, a security procedure accepted in writing and a test file from the client's own systems. Botminds' Treasury Management Onboarding is built for that second half. It does not replace the bank's systems; its agents read from them and draft into them, each value cited to the signed page, and named people approve before anything is applied.
The examples come from a fictional sample bank and client running through the solution. Regulatory expectations are linked where they appear.
Where commercial banking onboarding software stops
Banking onboarding software usually stops at the open, verified account, because that is the problem it was built to solve. Customer identification, business verification and beneficial ownership are well served by account-opening and KYC platforms, and the guides to KYC onboarding software and KYB verification cover that ground.
What comes next is different in kind. The client now needs users and entitlements in the digital banking platform; a company ID, permitted entry classes, cut-offs and an exposure limit in the payments hub; a positive pay file layout; a deposit capture configuration; and a signed agreement on how payment orders will be verified. Those are not account attributes. They are operating settings in other systems, and each must match a signed schedule. Software that collects them on a form and leaves someone to re-key them has moved the problem, not solved it.
What systems does a treasury implementation touch?
A treasury implementation touches at least six systems: two it configures and four it reads from. The OCC's ACH guidance describes the environment accurately: "Bank ACH systems use multiple applications, processing, storage, and communications systems that can be accessed by many internal and external users. Those systems may be operated by the bank, bank customers, or various service providers" (OCC Bulletin 2006-39).
Six systems a treasury implementation touches, and what it needs from each
| System | What the implementation needs from it | Read or write |
|---|---|---|
| Digital banking platform | The client's users, entitlements, approval limits and dual control | Write: configured after approval |
| Payments hub | ACH company ID, entry classes, limits and cut-offs; wire templates; positive pay layouts; test files | Write: configured after approval; test files read |
| Core banking system | Accounts, balances, history and the client's business record | Read |
| Client record | The relationship, the officer and the signed proposal | Read |
| Document imaging | The signed agreement, schedules, authorized-representative form and ownership certifications | Read |
| Account analysis system | Billing codes, and the first analysis statement after go-live | Read; codes set by its owners |
The same OCC bulletin adds a warning that applies to any new layer: "An effective ACH risk management program should be designed to coordinate with other retail and wholesale payment-risk management programs." A second place where entitlements or limits are decided, separate from the systems that enforce them, is the opposite of coordination.
The last row of the table is the one implementations forget. A service switched on in the payments hub without its billing code in the account analysis system is delivered every month and charged for none of them, and nothing in either system flags the gap, because each is working as configured. It surfaces only when someone compares what the client used with what it was billed; service codes and the unbilled service shows how a fee review finds one. Go-live is the cheapest moment to set the code, because the signed pricing schedule is on the desk.
Does onboarding software set up ACH origination?
Only if it can carry a credit decision, a signed schedule and a passing test file into the payments hub; software designed around account opening may stop short of all three. ACH origination has prerequisites no form can supply: an exposure limit set by credit before the first entry, the entry classes and company ID the client agreed, and a file from the client's own accounting system that passes. Nacha's risk staff describe the limit as a control that watches origination and returns across several settlement dates and by type of entry (Nacha, Why are Exposure Limits So Important?; how to calculate an ACH exposure limit sets out the arithmetic), which is configuration in the payments hub, not a field in an onboarding portal.
Ask any vendor to show ACH origination end to end on a sample client: the limit decision with its reason, the schedule values in the hub, a failed test file and the fix. Software that ends at "service requested" leaves the longest part of the implementation where it was.
Client onboarding software for financial services: three kinds
Three kinds of software answer to "client onboarding software" in banking, and they solve different problems. Buying one to do another's job spends the money and keeps the delays.
Three kinds of software, three different jobs
Account opening and KYC platforms: Verify the business, its owners and controllers; open the account.
Treasury implementation, as in Treasury Management Onboarding: Set up treasury services on the opened account and take the client to its first live payment.
Account opening and KYC platforms: Applications, identity documents, ownership certifications, risk ratings.
Treasury implementation, as in Treasury Management Onboarding: Signed schedules, setup fields with their sources, exposure limits, test files, second checks.
Account opening and KYC platforms: Core banking, to open the account.
Treasury implementation, as in Treasury Management Onboarding: Digital banking and the payments hub, after a person approves.
Account opening and KYC platforms: The account is open.
Treasury implementation, as in Treasury Management Onboarding: Every service is live, every prerequisite signed.
Account opening and KYC platforms: Corporate treasury management systems, which a client's treasurer buys to run its own cash; not a bank onboarding tool.
Treasury implementation, as in Treasury Management Onboarding: A replacement for the digital banking platform or payments hub; it drafts into them.
The two columns share one piece of data that matters in 2026. FinCEN's February 13, 2026 order lets a bank rely, for a new account, on beneficial ownership information a customer gave earlier, provided the customer certifies or confirms, verbally or in writing, that it is still up to date and accurate (FinCEN, FIN-2026-R001; the 2026 CDD relief quotes the order). A treasury implementation that opens new operating accounts benefits only if it can read what the account-opening side already holds. That is an integration requirement, not a feature.
Integrate, don't replace: drafting into the systems you run
Integration here means three things: read every source document and system the implementation depends on; draft each setting with its source beside it; and write to the live systems only after a named person approves. Replacement means moving entitlements, limits or files into a new system of record, which creates a second place to keep current and a second place for an examiner to test.
From signed schedule to live configuration, without a second system of record
Agent
Setup agent readsThe signed proposal and every product schedule from document imaging; the accounts and client record from the core.
Never: changes a signed term
Agent
Setup agent draftsEvery setup field for both systems, each citing its schedule and page; below the confidence floor, a field is held for a person.
Never: writes a live configuration
A person decides
Manager approvesThe implementation manager approves the drafted setup against the signed schedules, with a reason.
A person decides
Specialist appliesThe approved values are applied in the digital banking platform and the payments hub.
A person decides
Second implementer checksUsers, entitlements, limits and security procedures against the signed forms; removes what does not match.
In the sample, the Setup agent drafted 87 fields across four services and two systems from the signed proposal and four schedules. Twenty-six were flagged for a person's eye by design, and three were held because the agents' confidence fell below the bank's 0.90 floor. The rest were formats the schedules fixed. Clicking any value opens the signed line behind it.
Click a drafted value and read the sentence the client signed
What re-keying costs, and where it shows up
Re-keying a signed schedule into two systems costs less in typing than in errors found late. A wrong cut-off or a missing entitlement is rarely caught at configuration; it surfaces when the client's first file misses the window or a user cannot approve a payment, weeks later, in front of the client. The errors also have a direction: they drift toward the template the implementer started from and away from what this client signed.
The sample shows the pattern on a small scale. The second implementer checked 14 users, 31 entitlements, 4 limits and 3 security procedures against the signed authorized-representative form and schedules, and removed one entitlement: a wire-initiation right for a user who had it in the template but not on the client's form. Nothing about it was malformed. It was simply not what the client agreed, and an unchecked extra right to initiate wires is the kind of setting Article 4A cases are fought over.
Software that drafts from the signed page changes the error profile in two ways. A drafted value either matches its source or is flagged, so the template stops being the silent default. And the check that follows is a comparison of two things side by side, the configured value and the signed line, rather than a recollection. That is a check a second implementer can finish quickly and an auditor can repeat later without asking anyone what they remember.
Three settings deserve a source citation more than any others, because a wrong value in each costs real money: the ACH company ID, which ties every file to its agreement; the exposure limits, which the bank's credit function set; and the approval rules for wires, which carry the security procedure the client accepted. If a product cannot show where those three came from, it is not reducing re-keying risk, only relocating it.
What the regulators expect of the controls around it
Any software that touches entitlements and payment settings falls under the bank's access and authentication controls, and agents are no exception. The FFIEC's 2021 guidance defines its "users" to include "employees, board members, third parties, service accounts, applications, and devices", and expects least-privilege access: each user reaches only the systems its job needs (FFIEC, Authentication and Access, 2021; user access review software quotes the control and shows how a bank tests it). An agent that drafts setup fields needs read access to documents and write access to nothing live.
For client-side changes, the same guidance expects stronger authentication for account maintenance such as a new address, email, password, contact or enrolled device (the FFIEC authentication guidance). And for payment orders, Article 4A makes the security procedure something the client and the bank agree, not something either sets alone (UCC § 4A-201; the commercially reasonable security procedure test). Software can record the agreement and configure it; it cannot choose it for the client. Those boundaries are why the solution's governance separates seven roles by duty and refuses the configurer's signature on the second check.
How long does it take to implement onboarding software?
No public source measures implementation time for this kind of software, so treat any vendor's figure as a claim to test. The time is set by the integrations, and they come in a sensible order. Read-only access to document imaging, the core and the client record comes first and carries the least risk. Drafting comes second, with a person applying approved values by hand. Writing approved values to the digital banking platform and payments hub comes last, once the bank trusts the drafts.
The best test is a pilot on the bank's own material: a sample of its signed schedules, its service templates and past client test files, including some that failed. That shows whether the drafts match what the bank's people would have configured and whether the test-file explanations are right, before anything touches a live client.
Every implementation in flight, with what the agents found overnight
Integration questions to ask before you buy treasury onboarding software
Integration questions for treasury onboarding software
- Which systems does it read, and which does it write?
Writes should be limited to approved values in the digital banking platform and payments hub, and visible in their own logs.
- Does every drafted value cite its signed source?
Schedule and page, openable by the person approving. A value without a source is a value someone has to re-check.
- What happens when it is unsure?
A confidence floor below which a person reads the value, set by the bank and recorded.
- Can it set up ACH origination end to end?
Including the exposure limit request, the company ID and entry classes from the schedule, and the client's test files.
- Who can approve, and can anyone approve their own work?
Roles separated by duty; the system, not a procedure manual, should refuse a configurer's signature on the second check.
- What does the bank keep if it leaves?
The evidence file, audit trail and setups in formats the bank can read without the vendor.
- Will it run a pilot on our own files?
Signed schedules and past test files from the bank, scored by the bank's own implementers.
For the regulatory side of putting agents in this loop, see what an agent may set up at a bank; for the cost of the days the software should save, the steps, the days and their cost. The solution is at Treasury Management Onboarding.
Questions people ask
What is commercial banking onboarding software?
It is software that takes a business client from application to active services. In banking it usually means account opening and KYC; treasury onboarding software covers what follows, setting up ACH, positive pay, wires and deposit capture on the open account.
Is a treasury management system for banks the same as onboarding software?
No. A treasury management system usually means software a company's treasurer uses to manage its own cash and payments. The bank's side is its digital banking platform and payments hub, and treasury onboarding software sets clients up in them.
Should treasury onboarding software replace the digital banking platform's setup screens?
No. The platform is the system of record for users and entitlements, and examiners test controls there. Onboarding software should draft settings with their sources and apply them through the platform after approval.
Can onboarding software reuse beneficial ownership the bank already holds?
If it can read the account-opening records, yes. Since FinCEN's February 13, 2026 order, a bank may rely on earlier ownership information for a new account when the customer confirms it is still accurate, and must keep a record of that confirmation.
What should a pilot of treasury onboarding software measure?
Whether drafted setups match what the bank's implementers would configure, whether failed test files are explained correctly, and how many fields need a person. Run it on the bank's own signed schedules and past test files, not on vendor samples.