Commercial treasury conversion

Moving commercial clientsto a new treasury platform.

Commercial treasury is the most complex digital conversion. Payroll, payables, wires, positive pay, deposits and the files clients send from their own systems all have to keep working through the move.

  1. 01Technology conversion
  2. 02Conversion leadership
  3. 03Servicing & operations
  4. 04Products & services
  5. 05Clients & relationships
  6. 06Risk, fraud & compliance

What's involved

A treasury conversion is a client program as much as a technology one.

Each company, user, entitlement, limit, and template has to arrive intact. The platform providers help map the data, and run their conversion tools. The rest is on the bank to plan, staff, and execute.

01

Technology conversion

The stages that move every client intact, from architecture to the last wave's stabilization.

Who owns it
Your technology leaders and your treasury platform provider, with your core and payment providers.

Key projects

  • Architecture & integration inventoryThe core, payment hubs, positive pay, remote deposit, reporting, identity, fraud, and every client connection.
  • Entitlement & template conversionCompanies, users, accounts, services, limits, approvals, templates and payees.
  • Integrations & filesReal-time and batch connections to the core and the payment rails, and every client file format.
  • Client connectivityFile transfer and API connections, with new endpoints and credentials, tested with each client.
  • Testing & mock conversionsEnd-to-end payment scenarios, and repeated rehearsals of each wave.
  • Cutover & stabilizationWave runbooks, the payment switch, and hypercare through each wave's first payroll and month-end.
We lead

We own the eight stages below end to end, with your teams and your platform provider.

Talk with us about this workstream
02

Conversion leadership

Led by people who have run treasury conversions before, with one plan for treasury, technology, operations, sales and the vendors, organized around client waves instead of a single date.

Who owns it
Your head of treasury management as sponsor, with technology and operations leaders and a program office.

Key projects

  • OversightSponsor, steering committee, decision rights, and who can move a client between waves.
  • Integrated technical program planBuild, test, pilot and each wave on one plan, with the technical dependencies between platforms, vendors and teams mapped and aligned, around your clients' busiest days.
  • Vendor coordinationThe new platform, the current one's exit, and the payment, positive pay, remote deposit and reporting providers around them.
  • Risks, issues & decisionsOne register, reviewed weekly, with anything that touches a client flagged.
  • Budget & capacityImplementation specialists, support staff and relationship managers' time, planned wave by wave.
  • Go/no-go by waveCriteria for the pilot and each wave, and the evidence each one needs.
We lead

We run the program office and the wave calendar with your sponsor, and hold the vendors to the same dates.

Talk with us about this workstream
03

Servicing & operations

The servicing, payment operations, support desk and implementation teams that keep clients' payments running during the waves and after.

Who owns it
Your treasury servicing and operations, payment operations and client support leaders.

Key projects

  • Payment operations proceduresACH, wire, real-time and positive pay processing on the new platform, with its cutoffs and exceptions.
  • Client support deskStaffing, scripts and hours sized for each wave's first payroll and first month-end.
  • Implementation capacitySpecialists for enrollment, entitlement questions and file testing, wave by wave.
  • Internal trainingOperations, support, sales and relationship managers trained on the platform clients will see.
  • Exception handlingRejected files, held payments and positive pay decisions worked the same day on the new platform.
  • Running two platformsBoth platforms side by side until the last wave, with rules for which client is where.
We work alongside you

We size the support and implementation teams from the wave plan, and write the procedures from the platform as configured.

Talk with us about this workstream
04

Products & services

Each service your clients use, mapped to what the new platform does, with a decision for each gap.

Who owns it
Your treasury product managers, pricing and legal teams.

Key projects

  • Service mapping & gap analysisACH, wires, real-time payments, positive pay, remote deposit, lockbox, sweeps and reporting, old to new, feature by feature.
  • Gap decisionsFor each gap, build it, work around it, retire it, or tell the client.
  • Pricing & account analysisService codes, prices and analysis statements carried over, so the first bill matches what clients expect.
  • Agreements & service termsTreasury services agreements and service schedules updated where the platform changes the terms.
  • Limits & approval policyTransaction and daily limits, dual control and approval rules, set as policy before they become configuration.
  • Reporting & filesPrior-day and current-day reporting, statements, and the file formats your clients' systems depend on.
We work alongside you

We do the mapping and gap analysis with your product owners, and build what the platform doesn't do.

Talk with us about this workstream
05

Clients & relationships

Each client segmented, scheduled, informed, supported and converted, with relationship managers leading the conversation with their clients.

Who owns it
Your treasury sales team, relationship managers and client implementation team.

Key projects

  • Segmentation & wave planClients grouped by services, users, file connections and risk, with pilot clients chosen deliberately.
  • Relationship manager playbookWhat to say, when, and what each client has to do, before the first letter goes out.
  • Client communicationsLetters, guides, webinars and in-app messages, timed to each wave.
  • White-glove conversionsYour largest and most complex clients converted with a named specialist.
  • Client file testingClients who send files from their own systems test new connections and formats before their wave.
  • Enrollment & adoptionUsers re-enrolled, tokens delivered, and the clients who haven't logged in called before payroll day.
We work alongside you

We build the wave plan from your client data, run client file testing, and track each client until enrolled and active.

Talk with us about this workstream
06

Risk, fraud & compliance

Payment controls, fraud defenses and client access as strong on day one as they were the day before.

Who owns it
Your risk, fraud, BSA, information security and compliance teams.

Key projects

  • ACH origination riskOriginator limits, risk reviews and agreements carried across, in line with Nacha rules.
  • Entitlement & access reviewEach user's rights reviewed as they convert, and access nobody should still have removed.
  • Fraud controlsPayment fraud monitoring, out-of-band verification and alerts working on the new platform before the first wave.
  • Authentication & tokensMulti-factor authentication and token delivery for every user, without a gap.
  • Third-party risk managementDue diligence and oversight of the new provider, and an orderly exit from the old one.
  • Audit & evidenceEntitlement reconciliations, payment tests and sign-offs, organized the way auditors read them.
You own it, we feed it

We produce the evidence: entitlement reconciliations, payment test results and access reviews, client by client.

Talk with us about this workstream

Pilot and waves

Convert a pilot first, then clients in waves.

Most programs are planned back from a date fixed early. We'd rather plan forward based on the work, but either way, the order of the steps doesn't change.

  1. 01MobilizeGovernance, the integrated technical program plan, and the client data. Milestone: the wave plan.
  2. 02DesignService mapping, gap decisions and the entitlement model. Milestone: entitlements mapped.
  3. 03BuildConfiguration, integrations, files and client connections. Milestone: build complete.
  4. 04Test and mock conversionsPayment scenarios, then entitlement and template mocks and a wave rehearsal before the pilot, with no code changes between the final mock and the rehearsal.
  5. 05Client readinessThe relationship manager playbook, client letters and file testing. Milestone: every pilot client ready.
  6. 06PilotFriendly clients through a full payroll and a month-end. Milestone: pilot live.
  7. 07WavesSimple clients to complex, the largest with a named specialist. Milestone: each wave converted.
  8. 08Stabilize and decommissionHypercare for each wave, then the old platform decommissioned. Milestone: old platform decommissioned.
Client calendars

Plan each wave around payroll and month-end.

Keep each wave clear of payroll peaks, month-end, quarter-end and year-end tax filing, your clients' busiest days.

File clients start first

Their IT team works to its own schedule.

Clients who send files from their own systems need new connections, and time to test them, months before their wave.

Pilot first

Pilot with friendly clients, then grow the waves.

A pilot of willing clients using a representative mix of services proves the process. The most complex clients get their own dates and a named specialist.

How Ignite supports you

How we work on a treasury conversion.

Our practitioners have run treasury platforms inside banks and integrated them alongside the providers. We work between your treasury, technology and operations teams and your vendors, from the first plan to the last wave.

01

Before you mobilize

A practitioner's review of your plan, your wave approach, your client base and the decisions ahead, while changing course is still cheap.

02

Lead the technology conversion

The eight stages, architecture through the last wave's stabilization, owned end to end with your teams and your platform provider.

03

Deliver the technology platform

Entitlement and template conversion, client file testing, the integration build, or command of each wave's cutover, delivered by one accountable team alongside yours.

04

Recover a conversion that's slipping

A quick assessment of where it is stuck, then the people to fix it, without restarting the program.

What stays yours

Your client relationships, your decisions, your people, and your relationship with your provider.

What we take

The wave plan, the data, the build, the rehearsals, each cutover, and the evidence that each client arrived intact.

The technology conversion

The technology conversion runs in eight stages.

01Architecture

Map every connection between your clients' money and your systems.

A treasury platform sits between your clients and the core, the payment rails, positive pay, remote deposit, reporting and fraud systems, and often the client's own accounting system. Each connection needs an owner and a future.

  • The core: balances, history, memo posting and holds
  • Payment hubs for ACH, wires and real-time payments
  • Positive pay, remote deposit, lockbox and sweeps
  • Prior-day and current-day reporting, and statements
  • Identity: single sign-on, multi-factor authentication and tokens
  • Client connections: file transfer and APIs

Done when

Every connection has an owner, a target and a test, and every client connection is listed by client.

Where it slips

The platform's standard integrations are assumed to fit your core and payment hubs, and the differences surface in client testing.

What we own

The platform's architecture, with each connection to the core, the rails and your clients settled before the build.

02Strategy

Choose a pilot and waves, or one weekend, and how a wave rolls back.

When you control the timing, a pilot and waves contain the risk, because each wave proves the process before a larger one follows. When a merger or a core conversion sets one date, everything is rehearsed for that date.

  • A pilot and waves, or a single cutover
  • Clients grouped by services, users and file connections
  • Two platforms side by side, and which client is where
  • A wave calendar around payroll, month-end and year-end
  • Sequencing with a core conversion, if there is one
  • Rollback: how a client or a wave returns to the old platform

Done when

The wave plan names every client, the rollback path is tested, and the steering committee has approved both.

Where it slips

The program is planned as a single go-live, with no sequence that proves each step before the next one depends on it.

What we own

Delivery strategy: what changes, in what order, and how each wave proves itself before the next.

03Data

Translate each permission, limit and template along with the accounts.

Treasury data is a hierarchy: companies, users, accounts, services, limits, approval rules, templates, payees and scheduled payments. Two platforms rarely model it the same way, so mapping it is design work.

  • The company, user and account hierarchy
  • Service entitlements, limits and dual-control rules
  • ACH and wire templates, payees and beneficiaries
  • Recurring and future-dated payments
  • Positive pay issued items, alerts and report subscriptions
  • Cleanup: dormant users, orphaned rights and excess access

Done when

The entitlement model is mapped and signed, and a sample of real clients has been converted and checked by the people who know them.

Where it slips

Entitlements mapped one to one between platforms that model them differently, so users arrive with too little access, or too much.

What we own

Transformation logic for every entitlement, limit and template, with validation, remediation, and every change tracked.

How we use AI in data mapping without exposing customer data

04Build

Build the integrations, files and connections behind the platform.

The platform is configured with your services, limits and branding. The connections to the core, the payment rails and positive pay are built around it, file formats are translated, and anything the platform doesn't cover is built or worked around.

  • Platform configuration: services, limits, workflows, branding
  • Core and payment hub integrations, real-time and batch
  • File formats: ACH, positive pay, BAI2 reporting and custom files
  • Client-facing endpoints, keys and certificates
  • Single sign-on, multi-factor and token provisioning
  • Account analysis and billing feeds

Done when

Every payment type and file passes end-to-end tests through the rails' test environments, and every gap has a build or an accepted workaround.

Where it slips

The integration team learns what the existing systems do in the last month before go-live.

What we own

Integration build and testing beside your engineers and the platform provider, including the software no vendor sells.

05Convert

Rehearse each wave, then convert a pilot you can learn from.

Mocks move entitlements, templates and scheduled payments into a test environment and check them client by client. The wave rehearsal is the dress rehearsal, run on cutover timing with no code changes after the final mock; a small conversion whose mock 2 runs fully clean inside the window may not need it. The pilot then converts clients who agreed to go first.

  1. Mock 1Companies, users and entitlements load and map.
  2. Mock 2Templates, payees and scheduled payments arrive intact.
  3. Wave rehearsalA full wave on the clock, with enrollment and file switches.
  4. PilotFriendly clients live, every issue fed back before wave one.

Done when

Two mocks convert cleanly, the pilot runs a full payroll and month-end, and its issues are closed.

Where it slips

Real users first log in at the pilot, and the enrollment experience ends up designed around support desk calls.

What we own

Conversion of each entitlement and template, wave by wave, with defects tracked from the first mock to the pilot.

06Reconcile

Prove each user and limit arrived intact, and each payment runs once.

Treasury reconciliation covers rights and money in motion. Each user has the access they had and no more, and each scheduled payment runs once.

  1. 01Users & entitlementsEach user and each right, with nothing added.
  2. 02Limits & approvalsTransaction and daily limits, dual control and approval chains.
  3. 03Templates & payeesAmounts, accounts, beneficiaries and routing, field by field.
  4. 04Payments in flightRecurring, future-dated and awaiting approval, each scheduled exactly once.
  5. 05Files & reportingPositive pay, reporting and client files matching the core.

Done when

Every check is clean or explained for each client in the wave, and treasury, operations and risk have signed.

Where it slips

Entitlements reconciled by counts, not by rights, and the first sign of a missing approval rule is a payment released without it.

What we own

Every wave proven complete and correct against the source, client by client, before it counts as done.

How we accelerate reconciliation

07Cut over

Switch each wave between payment windows.

Each wave has its own runbook: changes frozen, payments in flight settled or carried, final data converted and checked, client connections switched, and the first payment windows watched.

  • A wave runbook with owners and checkpoints
  • A freeze on template and entitlement changes before each wave
  • Pending approvals, in-flight and future-dated payments
  • Payment cutoffs: ACH windows, wires and real-time payments
  • The file connection switch, client by client
  • Go/no-go and rollback for every wave

Done when

Every client in the wave can log in, pay and exchange files, and the first payment windows reconcile.

Where it slips

A wave switched across a payment window, with nobody owning the payments approved on the old platform but not yet released.

What we own

Wave runbooks and cutover command, with the rollback gate agreed before each wave.

08Stabilize

Stay through each wave's first payroll and first month-end.

Problems show up with the first payroll file, the first positive pay decisions and the first month-end analysis statement. Hypercare follows each wave until those have run clean, and ends when the old platform is decommissioned.

  • A hypercare desk for every wave
  • First payroll, positive pay and month-end watched
  • Enrollment and adoption: who hasn't logged in, who hasn't paid
  • Defect burn-down with the provider
  • The second platform retired after the last wave
  • Handover to the teams who will run it

Done when

Every client is enrolled and active, the last wave is through its first month-end, and the old platform is decommissioned.

Where it slips

The last wave declared done while clients still log in to the old platform, or don't log in at all.

What we own

Stabilization: adoption measured client by client, defects burned down, and the old platform retired.

Your decisions

Ten decisions only the institution can make, best made early.

Your provider and partners can recommend, but each of these moves the wave calendar if it's made late.

  1. 01

    A pilot and waves, or one weekend.

    Mobilize
  2. 02

    How the commercial treasury and core conversions are sequenced.

    Mobilize
  3. 03

    Which clients go first, and which get a named specialist.

    Design
  4. 04

    What happens to each feature the new platform doesn't have.

    Design
  5. 05

    How users re-enroll, and how tokens reach them.

    Design
  6. 06

    Which limits, approval rules and entitlements carry over, and which are reset.

    Design
  7. 07

    Whether pricing and agreements change with the platform.

    Design
  8. 08

    How long both platforms run side by side.

    Design
  9. 09

    What "converted" means for a client, and who signs it.

    Test
  10. 10

    The go/no-go criteria for each wave, and who can say no.

    Readiness

Commercial treasury and core together

If the core converts in the same program, decide the order early.

Your treasury platform reads balances, posts transactions and ties every client entitlement to core accounts, so converting the two on different dates means building that integration twice.

Option A

Core first, treasury after

CORETREASURY
Fits when
Your current treasury platform can connect to the new core, and the treasury team needs a settled core first.
The catch
Integration work for a platform you are about to retire, and your clients live through two changes.
Option B

Treasury first, then core

CORETREASURY
Fits when
Your clients need the new treasury platform sooner, or the core date is a long way out.
The catch
The new treasury platform is integrated to the old core, then again to the new one, and it has to be in every core mock.
Option C

The same weekend

CORETREASURY
Fits when
A merger or a provider exit forces one date, or your clients can absorb only one change.
The catch
All the risk on one weekend, no pilot and no waves, and a rollback that takes both with it.

ConversionIntegrated a second time

It depends on whether your current treasury platform can connect to the new core, how many clients send files from their own systems, whether account numbers change, and how much your teams can carry at once.

We help you make this decision in the first weeks, because it sets the calendar.

Read the core conversion guide

Questions

What treasury leaders ask before a conversion.

How long does a commercial treasury conversion take?

It depends more on decisions than on a typical number of months: the number of clients, how many send files from their own systems, whether the core is changing too, and how early the wave plan is settled.

Do we convert every client at once?

Not when you control the timing. Run a pilot and then waves, simplest clients first and the most complex on their own dates. When a merger or a core conversion sets one date, every client moves that weekend, and the rehearsals have to do the work the waves would have done.

Will our clients' users, passwords and tokens convert?

Companies, users, entitlements, limits and templates usually convert. Passwords and tokens usually don't, so every user re-enrolls. Design that experience as carefully as the data, because every client goes through it.

What about clients who send files from their own systems?

They need new connection details and credentials, sometimes new file formats, and time to test before their wave. Start early, because their IT teams work to their own calendars.

What happens to recurring and future-dated payments?

They convert or are recreated, and a reconciliation proves each one is scheduled exactly once. Payments approved on the old platform but not yet released need an owner on cutover day.

What does our provider do, and what's left to us?

The provider configures the platform, runs its conversion tools and supports each cutover. The service mapping, gap decisions, entitlement design, integrations, client communications, file testing, reconciliation sign-off and the go/no-go for each wave are yours. That gap is where commercial treasury conversions slip, and where we work.

Spend 30 minutes with us

Talk with us about your treasury conversion.

No pitch, no obligation. And if we're not the right team for it, we'll tell you that too.

Spend 30 minutes with usThe program register

Bring your roadmap.Partner with us.Let's connect.Send me the program register.

We'd love to hear what you're working on. No pitch, no obligation, and if we're not the right team for it, we'll tell you that too.The programs we have finished, by line of work and institution segment, and the stages each one ran through. We email it to you.

Enter your work email.