13.5 Implementing Treasury Products & Services: Bank Onboarding, TMS Deployment & Cutover

13.5 Implementing Treasury Products & Services: Bank Onboarding, TMS Deployment & Cutover

Executive Summary: Selecting a product and implementing it are separate competencies, and the 2026–2028 blueprint separates them. Task 5.D — "Implement treasury products and services (including banking products, treasury workstations)" — carries 2–4 scored questions. It is the task that turns the RFP of §9.1 and the TMS architecture of §13.1 into working infrastructure, and it is where most treasury technology value is actually won or lost.

---

1. The Implementation Lifecycle

Every treasury implementation — a new lockbox, a new pooling structure, a full TMS — follows the same eight stages:

[!WARNING] Stage 4 is the stage that destroys timelines. KYC/AML documentation and account opening routinely take 8–14 weeks for a multinational, longer where beneficial-ownership documentation must be gathered across jurisdictions. It runs on the bank's clock, not yours, and no amount of project pressure compresses it materially. Start it first.

---

2. Bank Product Implementation

Documentation and Onboarding

Before a single file moves, the bank requires: entity formation documents, beneficial ownership certification under the FinCEN CDD rule, board resolutions or delegations of authority, signer mandates and specimen signatures, tax forms (W-9/W-8 series), and — for cross-border structures — local regulatory filings.

Technical Enablement

The Testing Ladder

Testing is not one activity. A CTP is expected to know the sequence:

1. Connectivity test — can the systems establish an authenticated session at all?
2. Format validation — does the bank's parser accept the file structurally? Run with a zero-value or test-flagged file.
3. Penny test (zero-dollar or nominal-value test) — send a real transaction of $0.01 to each beneficiary account to prove routing and account details before any material value moves. This is the single most valuable control in a payment implementation, and it should be repeated for every new beneficiary bank, not just once per project.
4. Integration test — end to end from ERP through TMS through bank and back into reconciliation.
5. User acceptance testing (UAT) — the business, not IT, confirms the process works for real scenarios.
6. Exception-path testing — the step teams skip. Test a rejected payment, a duplicate file, a failed connection, a partial statement, and a payment above an approval limit. A system that has only been tested on the happy path is untested.
7. Security and disaster recovery testing — penetration testing where contractually available, and a failover rehearsal.

---

3. TMS Implementation Specifics

Beyond the bank layer, a treasury workstation implementation adds:

• Data migration. Existing debt schedules, investment positions, hedge relationships, entity hierarchies, and bank account inventory must be cleansed before loading. Data cleansing is consistently the most underestimated task in the plan — legacy spreadsheets contain duplicate accounts, closed accounts still listed as open, and signers who left the company.
• Interface build. ERP to TMS (accounting entries, AP/AR data), market-data feeds, bank connectivity, and the GL posting interface back to the ERP.
• Configuration versus customization. Configure inside the vendor's supported framework wherever possible. Custom code is the primary driver of failed upgrades — every future release must be regression-tested against it, and a heavily customized SaaS deployment forfeits the upgrade economics that justified SaaS.
• Entitlements and segregation of duties. Build the approval matrix in the system so that the maker/checker separation of §12.2 is enforced by software rather than by convention.
• Training and documentation. Role-based training plus written procedures. Vendor training covers the software; only internal documentation covers your process.

Cutover Strategy

Best practice for payment-critical implementations is a parallel run of at least one full business cycle — commonly one month, so that a month-end and a full reconciliation cycle are both exercised — followed by a phased cutover.

[!WARNING] Never schedule a cutover into month-end, quarter-end, or year-end close. Treasury and accounting resources are fully consumed, error tolerance is at its lowest, and any rollback happens under reporting deadline pressure. The corollary applies to seasonal businesses: a retailer does not cut over in November.

---

4. Backward-Planning a Critical Path

Scenario — Meridian Group must have a new global payments and TMS platform live on Monday, January 5. Planning backward from that date, with the sequenced minimums:

The critical path totals roughly 40 weeks before go-live, and the binding constraint is bank onboarding — which must launch in mid-May for a January go-live. Two structural lessons the exam rewards:

1. Onboarding runs in parallel with build, but it starts earliest. A team that begins KYC after contracts are signed and interfaces are built has already lost the timeline.
2. A December go-live for a calendar-year company is the wrong date regardless of readiness. Meridian's January 5 target deliberately clears year-end close.

---

5. Hypercare, Decommissioning & Benefits Realization

Hypercare — an elevated support period, typically 4–8 weeks — keeps the project team and the vendor engaged after go-live with a defined issue-triage path and daily standups. Releasing the project team on go-live day is a common and expensive error.

Decommissioning is a distinct workstream, not an afterthought:

• Close the superseded bank accounts formally, and remove the signers (see §9.3). An account left open with stale mandates is an open fraud channel.
• Revoke connectivity credentials and certificates for the retired service.
• Archive legacy data to satisfy retention requirements before switching off the old system.
• Stop paying for it. Legacy bank services and software licenses that were never cancelled are one of the most reliably recoverable costs in a treasury fee review.

Benefits realization closes the loop against the business case that funded the project:

Ongoing Vendor Assurance

Implementation does not end the diligence obligation. For any hosted service, obtain and read the provider's SOC 1 (financial reporting controls) or SOC 2 (security, availability, confidentiality) report annually, and specifically review the complementary user entity controls — the controls the report assumes you are performing. Those assumptions are frequently untrue at the client, and that gap is a standard audit finding.