Why the Vendor Was Never the Problem
The Real Failure Pattern Behind a Bad FinTech Stack Switch
THE QUESTION
Why the Vendor Was Never the Problem
Every FinTech stack switch starts the same way: a decision about which vendor to move to. A bank whose relationship-manager model stopped fitting. An accounting platform that can’t keep up with order volume. A payments provider whose pricing changed, or an invoicing tool a competitor’s finance lead won’t stop recommending. The decision gets real attention — a shortlist, a comparison, sometimes weeks of evaluation.
Then the switch happens, and it goes wrong in a way that has nothing to do with which vendor was chosen. A Direct Debit mandate doesn’t redirect in time and a supplier goes unpaid for a cycle. A reconciliation breaks mid-month because both systems were live and nobody was checking them against each other. A customer’s saved card details don’t migrate to the new invoicing tool, so their renewal silently fails three weeks later. An old account gets closed a week too early, before the last mandate has finished moving.
None of these are vendor problems. They’re sequencing problems — and the pattern holds regardless of which layer of the stack is switching or which vendor was picked. This piece is not a vendor comparison; it argues the opposite point, that the vendor comparison is the part of a switch operators already handle reasonably well, and that virtually all of the operational risk sits somewhere else entirely: in the order operations happen, not in which providers are involved.
That distinction matters because it changes where an operator should spend their attention. Weeks spent optimising a vendor shortlist by another percentage point of pricing or another integration feature produce diminishing returns fast. An hour spent mapping what actually depends on the system being switched, before any vendor conversation goes further than a shortlist, prevents the failure modes that do the real damage — the ones that show up as a missed payment, a broken reconciliation, or a customer’s phone call asking why their subscription stopped working.
This is not an argument that vendor choice doesn’t matter at all — a genuinely poor-fit provider creates its own problems downstream, and the evaluation work in Chapter 1 of the Playbook this piece draws from is real and worth doing properly. It’s an argument about where the risk actually concentrates once a reasonable shortlist exists. Two operators can pick equally good providers and end up in entirely different places three months later, purely on the strength of how the switch itself was sequenced — and the operator who assumed a well-chosen vendor would make the transition self-managing is usually the one explaining a missed payment to a supplier who’s now asking for terms upfront on the next order.
THE LANDSCAPE
Forced Versus Chosen, and the Four-Layer Hierarchy
Stack switches happen for one of two structurally different reasons, and the distinction shapes everything that follows.
Forced switches arrive on a timeline the operator doesn’t control — a vendor exit notice, an account closure, a payments processor terminating an agreement. These compress the sequencing work that follows into whatever window remains, and they carry the highest immediate risk precisely because there’s less time to do the dependency-mapping work properly before cutover.
Chosen switches happen because the operator has decided the current provider no longer fits — outgrown reporting capability, a relationship model that stopped matching the business’s actual needs, better economics elsewhere. These carry lower time pressure but a different risk: without an external deadline forcing discipline, the dependency-mapping work is easier to skip or rush, on the assumption that “we have time to fix anything that comes up.”
Both routes into a switch touch the same underlying structure: a four-layer hierarchy of what a business’s FinTech stack actually depends on, in order of consequence if something breaks. At the base sits the bank account itself — everything else ultimately settles through it. Above that sit the payment rails and mandates that move money in and out — Direct Debits and standing orders in the UK, ACH authorisations and card-on-file arrangements in the US, each with its own redirect mechanics that don’t map cleanly onto the other market’s. Above that sits the accounting and reconciliation layer — the ledger that has to keep tying out through the transition. And at the top sits payroll, which this piece treats, deliberately, as its own category rather than one line among many.
Payroll’s position at the top isn’t about volume — for most SMBs it’s a small number of transactions relative to the customer and supplier payment book. It’s about consequence. A missed or delayed payroll run carries immediate staff-trust damage and statutory consequences that are entirely independent of why the payment was late — HMRC’s Real Time Information reporting obligations in the UK, and EFTPS federal and state payroll tax deposit penalties in the US, both continue regardless of which account payroll happens to be running through that month. Every other failure mode in this piece is recoverable with an apology and a fix. A missed payroll run is not treated the same way by the people it affects, and shouldn’t be treated the same way in how a switch is sequenced.
The rail mechanics themselves diverge sharply between markets, which is worth naming explicitly for any dual-market UK/US business reading this. In the UK, Faster Payments handles the near-instant majority of transfers, CHAPS handles same-day high-value payments, and the Current Account Switch Service (CASS) — for eligible current accounts — provides a guaranteed, automated redirect of Direct Debits and standing orders for a fixed protection period. The US has no equivalent guaranteed-redirect service: the ACH network, governed by NACHA rules, handles the batch-cleared majority of recurring payments at one-to-two-day settlement, Fedwire handles same-day high-value transfers, and two newer real-time rails — The Clearing House’s RTP network and the Federal Reserve’s FedNow service — are expanding same-day coverage without yet reaching the universal bank participation Faster Payments has in the UK. A UK operator who assumes CASS-style automation exists on the US side of a dual-market switch is planning against a service that doesn’t exist there.
The accounting and invoicing layer carries its own version of this divergence, in vendor landscape rather than rail mechanics. Xero and QuickBooks dominate SMB accounting in both markets, with Sage and FreeAgent holding meaningful UK-specific share and NetSuite typically entering the picture once a US business scales past the point a pure SMB platform comfortably serves — usually signalled by exactly the kind of reporting-capacity strain that drove Meridian Fulfillment’s switch, discussed below. Invoicing and accounts-receivable tooling is sometimes built directly into the accounting platform and sometimes sits as a separate layer on top, handling dunning, payment links, and recurring billing while the accounting platform itself stays focused on the ledger — a distinction that matters because a switch at the accounting layer doesn’t automatically carry the invoicing layer with it, and operators who assume it does are one dependency-mapping step away from finding out otherwise mid-migration.
What actually triggers a switch splits fairly cleanly along the forced-versus-chosen line drawn above, and the split matters for how much runway an operator has to do the sequencing work properly. Forced triggers cluster around three patterns: a provider exiting a market segment or product line entirely, a processor terminating an agreement over a risk or compliance judgement the operator may not fully understand or agree with, and a straightforward account or facility closure with a notice period that’s rarely generous. Chosen triggers cluster around growth outrunning what the current stack was built to handle — the reporting ceiling Meridian hit, the relationship-model mismatch Thornbury hit — or, less dramatically, a straightforward commercial decision that a competitor’s pricing or feature set has pulled meaningfully ahead. Neither trigger type changes the sequencing work itself. What changes is the time available to do it, and forced switches are where compressed timelines make skipping the dependency map most tempting — and most costly when skipped. An operator navigating a forced switch on a genuinely short timeline should still find the time for the mandate inventory specifically, even where the fuller dependency-mapping exercise has to be compressed — it is the single highest-priority piece of work in this framework regardless of how much runway remains, precisely because it maps most directly onto the failure mode most likely to produce an immediate, visible problem.
THE MECHANISM
The Five Ways a Switch Actually Fails
Stripped of vendor specifics, nearly every failed FinTech stack switch traces back to one of five sequencing failures — and each has a specific, named fix. None of the five require specialist tooling or outside expertise to close; all five require deciding, in advance, that they’re worth the two-to-four-hours-a-week discipline this piece keeps returning to, rather than trusting that a well-chosen vendor will absorb the risk on the operator’s behalf.
Switching a layer without mapping what depends on it
The single most common failure mode, and the one every other failure on this list tends to trace back to. An operator moves to Chapter 1’s vendor conversation — evaluating providers, comparing pricing — before establishing what currently depends on the layer they’re switching. The fix is treating dependency mapping as mandatory groundwork that happens before any vendor conversation goes further than a shortlist, not optional documentation that gets done later if there’s time. Mapping outward in both directions from the layer being switched — what feeds into it, what depends on it — surfaces connections that don’t announce themselves. A warehouse-management system posting nightly inventory-cost journal entries. A multi-state sales-tax calculation add-on filing returns off the existing ledger. Neither looks like “an accounting dependency” until the accounting platform underneath them changes.
Missing a quiet, infrequent, or forgotten mandate
Every missed payment, every duplicated charge, and every angry supplier or customer call that follows a badly run switch traces back to an incomplete mandate inventory — a recurring payment relationship the operator either didn’t know existed or assumed would “just carry over” without specific action. Quarterly and annual payments are the most common casualties, precisely because their infrequency means they’re least likely to be top of mind when the inventory gets built. The fix is a genuinely complete inbound-and-outbound inventory, worked to actual completion rather than assumed finished once the obvious monthly items are listed.
Running a cutover with no parallel period
Cutting straight from old system to new, with no window where both run simultaneously and get cross-checked against each other, removes the only mechanism that would catch a problem while it’s still small. The fix is a minimum one-billing-cycle parallel run, reconciled at least weekly rather than only checked once at the end. A discrepancy caught in week one against a fresh comparison is a five-minute fix. The same discrepancy, undetected and compounded across three further weeks of transactions built on top of it, is a materially longer one — and by the time it surfaces, it’s harder to isolate exactly where the numbers diverged.
Publishing new bank details without building in verification
The cutover period is precisely when businesses are most vulnerable to bank-detail-change fraud, because a message announcing new account details looks completely ordinary during a switch — where it would be a clear red flag at any other time. The fix is treating every bank-detail-change communication, to every supplier and customer who needs one, as a fraud-prevention moment specifically — a verified callback to a known number, not just an email announcement — rather than only an operational one.
Closing the old account or contract before every mandate is confirmed complete
The final and, in some ways, most avoidable failure: closing the old provider down on the first date that feels safe enough, rather than confirming every single mandate has actually redirected. The fix is a deliberate dormancy period — keeping the old account open but unused for a defined stretch, typically a full billing quarter — combined with an explicit off-boarding checklist, so closure happens on the operator’s terms once everything is genuinely confirmed complete, not on an assumption.
What getting this wrong actually costs
None of the five failure modes above are hypothetical, and none carry a cost that shows up conveniently in one place. A missed supplier payment costs the direct late-fee or interest exposure, but far more often costs a relationship — a supplier who has to chase for payment once starts asking for terms, or advance payment, on the next order, quietly worsening the business’s working capital position for months after the switch itself is long forgotten. A missed customer renewal costs the immediate revenue, plus whatever it costs in support time to identify and manually re-collect it, plus a small but real chance the customer simply doesn’t come back rather than dealing with the friction. A reconciliation that doesn’t tie out costs finance-team hours that scale with how long the discrepancy went undetected — the difference, as the parallel-run section above argues, between a five-minute fix in week one and a multi-day forensic exercise in week four.
Set against that, the cost of doing the sequencing work properly is almost entirely time, not money. A dependency map, a mandate inventory, and a weekly parallel-run cross-check are spreadsheet-level tools — no specialist software, no external consultant, typically two to four hours a week of an operator’s or finance lead’s time across the length of the switch. The asymmetry is the entire argument of this piece: the failure modes are expensive and compounding: the fix is cheap and mechanical, and the only reason it doesn’t happen by default is that nothing about picking a new vendor forces an operator to do it.
THE PLAN
The Sequenced Path Through a Switch
Weeks 1–2: scope, and choose deliberately
Before any vendor shortlist, name the outcome precisely: what “done” looks like for this specific switch, and what’s explicitly out of scope. Run the fit check — is this a straightforward single-layer switch, or does it touch multiple entities, cross-border treasury structures, or a genuinely adversarial outgoing-provider relationship that needs a different kind of support entirely. For most single-layer switches, work the vendor evaluation against a fixed menu — bank, payments provider, accounting platform, or invoicing tool — checked in the UK against the FSCS-versus-safeguarding protection question, and in the US against FDIC coverage where relevant, before signing anything.
By the end of week two, the operator should hold either a signed new provider or a shortlist of no more than three, each checked against the relevant protection-regime question for its market. Resist the temptation to carry an open-ended shortlist into the next phase — dependency mapping is considerably more useful once there’s at least a provisional target to map toward, even if the final choice isn’t locked yet.
Week 3: build the dependency map
Before contacting any new vendor in earnest beyond an initial shortlist conversation, build the single-page map of everything touching the layer being switched — every system, every mandate, every integration, working outward in both directions. What feeds into the layer being switched today, and what depends on it — what would stop working, or start producing wrong numbers, if it went down for a day? Flag payroll explicitly and sequence it last, regardless of what else the map contains. Include a fixed prompt list — CRM, e-commerce or point-of-sale, expense management, any covenant-linked reporting — rather than relying on whatever comes to mind that day, since the whole value of this exercise is catching the connections that don’t announce themselves. This map becomes the reference document every later step checks against.
Weeks 4–5: the mandate inventory
Build the complete inbound-and-outbound payment mandate inventory — every Direct Debit or ACH debit authorisation currently pulling money, every card-on-file subscription, every standing order or recurring transfer going out. List inbound and outbound mandates separately, since they live in different systems and migrate through different mechanics: inbound customer collections typically sit with a payments processor or invoicing tool, while outbound supplier and contractor payments typically sit directly with the bank. Pay particular attention to quarterly and annual items — a supplier retainer paid four times a year is easy to miss entirely when the inventory-building conversation naturally gravitates toward the monthly items everyone thinks of first. This is the chapter operators are most tempted to compress, and the one this piece argues most strongly against compressing, given how directly it maps to the most common failure mode above.
Weeks 5–7: parallel run
Bring the new system live alongside the old one, and run both for a minimum of one full billing cycle — longer where quarterly or annual mandates mean a shorter window wouldn’t capture a full cycle of every payment type. Reconcile weekly, not just at the end. Build in bank-detail-change verification for every communication going out during this window, treating the period as elevated fraud risk by default.
Week 8: cutover and close-out
Choose a cutover date deliberately — avoiding the final week of a VAT quarter or US sales-tax filing period, and never inside a payroll run rather than cleanly between two of them. On the day itself, confirm every mandate flagged as pending now reads confirmed complete before proceeding. Once cutover is stable, hold the old provider dormant rather than closing immediately — a full quarter is a reasonable default — and work the formal off-boarding checklist once every mandate is genuinely confirmed rather than assumed. Close with a brief retrospective: what took longer than expected, what the dependency map missed on its first pass, and what would run differently next time.
THE WORKED EXAMPLE
Thornbury & Co: A Bank Switch That Didn’t Miss a Payment
Thornbury & Co, a UK B2B marketing agency on roughly £1.2m turnover, faced a chosen rather than forced switch. Its high-street bank’s relationship-manager model, built around a straightforward domestic supplier book, stopped fitting as the agency grew to pay a meaningful share of contractors and platform subscriptions in euros and dollars. Nothing about the old bank had failed outright — it had simply become the wrong fit for a business whose structure had moved past what it was built to serve.
Thornbury shortlisted two challenger banks with stronger multi-currency handling, checked both against the FSCS-versus-safeguarding protection question before signing anything, and confirmed Current Account Switch Service eligibility — the automated, guaranteed mandate-redirect mechanism available for eligible UK current accounts, and one of the clearest structural advantages a UK operator has that a US equivalent switch simply doesn’t.
The dependency map, built in week three, surfaced what the vendor comparison alone never would have: the specific rhythm of Thornbury’s own mandate book. Rather than the Playbook’s one-month parallel-run minimum, the team chose to run five weeks, specifically because two supplier retainer payments in the outbound mandate inventory were paid quarterly rather than monthly, and the team wanted at least one of those less-frequent cycles to complete before fully trusting the new account over the old.
That extra discipline paid off in week one of the parallel run, not week five. The weekly cross-check caught a discrepancy immediately: a Faster Payments transfer that landed a day later than the equivalent transfer had historically taken on the old account. It wasn’t an error — simply a different bank’s processing rhythm, previously invisible because nothing had ever required comparing the two side by side. Logged and understood within the first week, it never became the kind of unexplained gap that causes genuine concern when a payment appears to be “missing” against old expectations built on the previous bank’s timing.
Cutover itself followed the sequence directly: every mandate confirmed complete before the switch, payroll moved only after smaller, lower-consequence payments had proven the new account through at least one full cycle, and the old account held dormant for a full quarter rather than closed at the first date that felt safe enough. Not one payment — to a supplier, a contractor, or an employee — was missed or duplicated across the entire switch. The full mandate inventory ran to just under forty separate items once quarterly retainers, annual software renewals, and a handful of infrequent supplier payments were properly captured — more than double what an informal, memory-based list drawn up in the first planning conversation had produced, which is itself a useful data point on how easily this specific piece of the work gets underestimated when it isn’t treated as its own dedicated inventory exercise.
The equivalent US case, Meridian Fulfillment — an e-commerce fulfilment business migrating from a smaller accounting platform to NetSuite as order volume outgrew what the old platform’s reporting could handle — makes the same underlying point from a different layer of the stack. Its dependency map surfaced a warehouse-management integration and a multi-state sales-tax add-on that nobody on the team had previously thought of as “accounting-adjacent” — both rebuilt and tested during the parallel-run window rather than discovered broken after cutover, when the cost of finding out would have been considerably higher. Meridian’s parallel run also caught a smaller but instructive issue: the sales-tax add-on’s multi-state filing schedule didn’t align cleanly with NetSuite’s default reporting periods out of the box, a mismatch that would have produced a materially wrong first filing had it surfaced after cutover rather than during a week when both systems’ numbers could still be checked side by side against the old platform’s known-correct output. Resolving it took a single afternoon of configuration work once flagged during the parallel window — the same fix, discovered instead from an incorrect filing three weeks after cutover, would have meant unwinding and refiling against a state tax authority, a materially longer and more consequential piece of work for a problem that was, at root, a configuration mismatch rather than anything genuinely complex.
Neither business’s story is really about which bank or which accounting platform won the shortlist. Both are about the same structural fact: the vendor comparison is the part of a switch that gets attention by default, and the sequencing work — the part that actually determines whether the switch goes well — is the part that has to be built in deliberately, because nothing about choosing a new provider forces it to happen on its own.
The 2028 baseline this catalogue is built against doesn’t assume every UK or US SMB will avoid ever needing to switch a FinTech stack component — growth, forced provider exits, and simple better-fit decisions make that unrealistic. It assumes operators can run a switch, whenever one lands on their desk, as a sequenced process rather than a single cutover event — and that the difference between Thornbury’s clean, uneventful transition and a badly run equivalent isn’t luck or vendor quality, but five specific, nameable pieces of groundwork that either got done or didn’t. For operators with a switch on their own desk, the full sequencing framework — the dependency map, the mandate inventory, the parallel-run tracker, and the rollback plan built before any of it starts — is what the Switching FinTech Stack Playbook hands over in working, ready-to-use form.
Read also
Switching FinTech Stack Playbook — the full eight-week sequenced guide this piece draws from. Open Banking & Data Layer Capsule (CAP-005) — for the bank-connectivity layer specifically, in scoping. Tool-Stack Integration Capsule (CAP-017) — the shorter, single-capability version of this piece’s dependency-mapping work, for an additive tool decision rather than a full switch.
