Day One Readiness
Pay your people and suppliers from the first morning.
Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.
TSA bank connectivity cutover moves the payment files, statements, and host-to-host links of the carved-out entity off the seller's banking setup and onto its own rails before Day One. Opening accounts is the easy part; getting a payment to actually leave them is the work. This is core launch plumbing, which places it inside day one readiness. Get it wrong and payroll and supplier runs stall on the first morning.
Bank connectivity is the set of pipes that carry money and information between a company and its banks. It is the host-to-host file transfer or API link that sends a payment batch, the channel that pulls back account statements, the security certificates and keys that authenticate every message, and the file formats the bank expects. Inside the seller's group, all of that ran on the seller's treasury platform, the seller's certificates, and the seller's bank relationships. The carved-out entity simply submitted its payments into that machine.
A cutover means rebuilding that machine for the standalone entity. New accounts, in the entity's own name, need their own connectivity to the bank, their own certificates, their own file formats agreed with the bank, and their own statement feeds back into the entity's accounting and reconciliation. None of this is visible to anyone until a payment fails, which is exactly why it gets underestimated. The accounts being open is mistaken for the entity being able to pay.
So the buyer treats connectivity as a distinct workstream, not a footnote under account opening. The accounts hold the cash; the connectivity moves it. A standalone entity that can hold cash but cannot reliably send a payment file or read a statement is not Day One ready, however healthy its opening balance. The connectivity is what turns an open account into a working one.
Start with how payments leave the entity. Most carve-outs run payment batches over a host-to-host link or a bank API, and the entity needs its own version provisioned with the chosen banking partner. That means agreeing the file format the bank accepts, exchanging and installing the security certificates, and mapping the entity's payment system output to what the bank reads. A format mismatch as small as a wrong field length will reject a whole batch, so the mapping is pinned down and tested rather than assumed.
Then statements coming back. The entity needs its bank statements flowing into its own reconciliation process, in the format its accounting system expects, on the schedule it needs to close each day. Inside the group this feed existed and someone else maintained it. On its own the entity has to set up the statement channel, confirm the file lands, and check it reconciles against the ledger. A standalone entity that cannot see its own bank balance cleanly each morning is flying blind on cash.
The control layer sits over both. Who can create a payment, who approves it, what limits apply, and which signatories the bank recognises all have to be configured for the new entity. Removing the entity from the seller's centrally controlled platform also removes the controls that platform enforced, so the buyer rebuilds the approval workflow and signatory list deliberately. This payment control work is part of the wider standalone treasury that the related treasury cash-pooling exit sets up.
The hardest constraint in this workstream is that the buyer does not set the pace. Opening corporate accounts, completing know your customer checks, provisioning host-to-host connectivity, and exchanging certificates all run on the bank's internal timelines, and those can stretch to many weeks regardless of how urgent the deal feels. A buyer that waits until the separation date is near to start the banking work discovers the connectivity cannot be ready in time, and the entity is forced onto a temporary dependence on the seller it did not plan for.
So the sequence starts the moment the banking partner is chosen. Accounts open first, because connectivity provisioning needs live accounts to point at. Certificates and file formats follow, then the test cycle, then the live cutover. Each step depends on the one before, so a delay early in the chain pushes everything back, and the test window is the first thing squeezed when the start was too late. The buyer protects the test window by starting the chain early.
Where the timeline genuinely cannot fit before Day One, a short bridging arrangement is negotiated honestly rather than discovered by surprise. A defined, time limited reliance on a payment path the seller provides, with a firm exit date and the standalone rails being built in parallel, is far better than an entity that arrives at Day One unable to pay. The point is to plan the dependency, not to back into it.
A connectivity cutover is proven by sending a real payment through the full path, not by confirming the link was configured. The standard is a penny test: a tiny live payment that travels from the entity's payment system, through the host-to-host link, into the bank, and out to a real beneficiary, with the statement coming back to confirm it cleared. If the penny test works, the path is proven. If it fails, the buyer would much rather find out on a one cent payment than on a full payroll run.
The test also covers the formats that will carry real volume. A single test payment proves the link; running a representative batch in the agreed file format proves the entity's actual payment files will be accepted. Payroll, supplier payments, and any direct debit collections each have their own format and their own quirks, so the buyer tests the formats the entity will rely on in week one, not just the simplest case. A link that passes a single payment but rejects the payroll file format has not really been proven.
Statements and reconciliation get the same treatment. The buyer confirms the statement feed lands in the right format, on the right schedule, and reconciles cleanly against the ledger, because a payment that goes out but cannot be matched back is only half a working process. Confirming both directions, money out and information back, is what lets the entity close its first day cleanly. This launch testing is the kind of proving the Day One Readiness program drives across every standalone function.
The cutover itself is a coordinated switch, not a drift. The entity stops submitting payments through the seller's path and starts running them through its own rails on a planned date, with the test cycle already complete and the controls already live. Doing this as one clean switch, rather than letting some payments run on the old path and some on the new, avoids the confusion of split rails where it is unclear which channel a given payment took. The buyer picks the date and runs the switch as a single event.
The first live run gets watched closely. The first real payroll and the first real supplier batch on the new rails are monitored end to end, with someone confirming the files were accepted, the payments cleared, and the statements came back, so any issue is caught within the run rather than discovered when a supplier or an employee complains. Treating the first few runs as a supervised stabilisation period, not a finished handover, is how the buyer keeps a small glitch from becoming a missed payroll.
Bank connectivity cutover rewards the buyer that respects how invisible and how unforgiving it is. Rebuilding the links and formats, starting on the bank's timeline, testing the full path with a penny payment, controlling the switch, and watching the first runs lets the standalone entity pay its people and its suppliers from the first morning. Treating connectivity as a box under account opening is how a carve-out with healthy cash still cannot get a payment out the door on Day One.
It is the move of the payment files, bank statements, and host-to-host or API links off the seller's banking setup and onto the standalone entity's own rails. The entity has to be able to send payments and receive statements through its own connections from Day One, rather than routing through the seller's treasury systems.
Sometimes it can for a short period, but the seller's links carry the seller's certificates, file formats, and approval controls. The new entity needs its own accounts, its own connectivity, and its own controls, and the longer it leans on the seller's plumbing the harder the eventual cutover becomes. Standing up its own rails early is the cleaner path.
A failed payment run on Day One. If the host-to-host link, the file format, or the signatory setup is wrong, payroll and supplier payments do not go out. The fix is to test the full path from beginning to end before go live, including a penny test payment, so the first real run is a repeat of something already proven.
Early. Account opening, connectivity provisioning, and certificate exchange run on the bank's timelines, not the deal's, and can take many weeks. The buyer starts the account and connectivity work as soon as the banking partner is chosen so testing is finished well before Day One.
Leaving the seller's cash pool and standing up standalone liquidity.
Read the article →The registrations the first standalone payroll run depends on.
Read the article →Standing up supplier payments the new entity runs on its own.
Read the article →The 90-day governance, IT, finance, HR and procurement separation plan we run on live carve-outs. Get the playbook plus the bi-weekly Day One Letter — short, signal-heavy, buyer-side.
No spam. Unsubscribe in one click. · Read the overview first →
Fixed-fee proposal in 48 hours. Senior team on day one. The first conversation is always free.
Seven buyer-side moves to exit a Transition Services Agreement on time and below budget. The mark-up, the extension-fee curve, exit sequencing, and the 11-month calendar.
One tactic, one benchmark, or one pattern from a recent buyer-side engagement. Short. Signal heavy. Free.
Subscribe to The Day One Letter →