FinTech Interview with Daniel West CEO at InstaSwitch: Inside banking infrastructure, Daniel West explains building InstaSwitch to fix account activation gaps.
Daniel, you came from a legal and industry-facing background. Could you walk us through your professional journey and what led you into financial infrastructure?
My background is legal, sales, and operational, not engineering. I came to this problem by working at a company providing embedded finance infrastructure, the infrastructure behind business banking products at some of the largest software platforms in the country. In that role, I watched something that didn’t make sense: companies were opening business bank accounts, and a large share of them never became operational. No income moved, no payroll switched.. The accounts existed on paper and did nothing. I started talking to customers. The answer was friction, not apathy. That’s what got me thinking.
Building a switching layer for banks isn’t the obvious path for someone without a technical background. What made you believe you could take this on?
I didn’t think of it as a technical problem at first. I thought of it as a workflow problem, and workflow problems I understood. The question wasn’t whether I could write the code. It was whether I understood the problem well enough to know what needed to be built, and why nobody had built it yet. So before we wrote a line of automation code, we did 300 manual switches. Every portal, every edge case, every compliance constraint, mapped by hand. That process is why InstaSwitch works. It’s built around how the problem actually behaves, not how anyone outside it might assume it does.
At what point did this shift from “someone should build this” to “I have to build this”?
There wasn’t a single moment. It accumulated. I kept having the same conversation with banks and fintechs where everyone acknowledged the problem and moved on. Accounts open, never activate, revenue walks out the door, and the institution launches the next acquisition campaign. I also saw what banks were doing instead: account managers manually walking clients through PDF-based workflows, one business at a time. Some institutions were spending headcount annually to manage what should have been an automated process. About 5.4 million U.S. small businesses attempt to switch bank providers each year, and most never complete the move.
What did you get wrong in the early days, and how did those mistakes shape the product?
In early conversations, traditional banks were telling us this was a top one or two priority problem. We chased that signal and focused on hosted deployments with zero engineering required, thinking we could move fast. What we didn’t realize is that bank diligence (InfoSec, legal, compliance) takes months no matter how light the technical lift is. So we ended up building a bank-grade product, which was the right call, but to get to revenue faster, the demand signal came from digital-first players: fintechs acquiring bank charters, neobanks trying to deepen relationships. They feel the activation gap more acutely because their whole model depends on becoming the primary account. That changed how we sequenced the early customer base. The other thing those 300 manual switches taught us was where the real technical problem actually lives. Connecting to a bank is the easy part. Executing authenticated workflows across third-party portals that were actively designed to block automation, that’s the hard part. That’s the architecture we built around.
What did you observe from inside the industry that more technical founders were overlooking?
I saw it from the outside, which was the advantage. I was watching banks and fintechs operate up close, and I could see that the activation gap was real, measurable, and everyone had quietly accepted it. Technical founders tend to look at account switching and see an API problem. But the harder problem is organizational: who actually owns activation inside a bank? It lives in the seam between digital, marketing, product, and revenue. That diffusion of ownership is exactly why it persisted. You only learn that from being in the room.
Why has the activation gap remained largely invisible despite its massive impact on lifetime value?
Because it shows up in absence. Banks track what happens: deposits, transactions, product adoption. They aren’t tracking what doesn’t happen. The payroll that never moved. The income that stayed at the old institution. They are not always tracking what does not happen, the payroll that never moved, the direct deposit that stayed at the old institution. The revenue impact does not show up cleanly in a dashboard. It shows up as a customer who opened an account, never became primary, and eventually churned. The data is clear: accounts where income switches within the first seven days of opening deliver 95% higher lifetime value. That gap is the activation problem, priced out.
Inside a bank, who actually owns customer activation, and why has that ambiguity allowed this to persist?
Nobody owns it fully, and that is the whole problem. Different business units own different things: the onboarding flow, the branch relationship, the feature set.. But whether income and payroll actually move falls into the seam between all of them. No one has a budget line for it, no one has a KPI that captures it cleanly, so it never gets solved. We built the infrastructure that lets institutions assign ownership to the outcome itself.
Why is account switching still largely manual or fragmented in an era of advanced fintech infrastructure?
Because the hard part is not connecting to a bank. It is executing authenticated workflows across third-party portals that were never designed to be automated. Payroll providers, merchant portals, HR systems, none of these were built with automation in mind, and many are actively designed to block it. Nobody built the updated infrastructure for business banking. Switching a business account means updating income, payroll, spend, vendors, and clients. Each through a separate portal, separate login, separate manual steps. It’s a meaty problem and that workflow did not exist anywhere before we built it.
How did your non-technical background shape how you approached building this?
I came in through the customer experience and the institution’s operational reality. Not through what was technically possible. That meant I was asking why this keeps failing before I ever asked how to build it. The answer was a workflow execution problem with no infrastructure behind it. The architecture we landed on reflects that: we use navigation and discovery to map where payment information lives across third-party portals, and then rule-based logic to execute the actual updates. That second part is non-negotiable in banking. PII cannot flow through an AI agent. Deterministic execution is how you meet compliance requirements without sacrificing automation. A pure engineering mindset might have built something elegant that could not clear bank diligence. We built something that did, and we have cleared diligence at a $40 billion financial institution.
For founders who don’t fit the traditional mold of the problem they’re trying to solve, what advice would you give?
Credentials tell you what someone has already done. Conviction tells you what they are willing to figure out. I didn’t have an engineering background. I had years of direct observation of a problem costing the industry billions, with no real solution. That observation was the asset. The rest was building the right team, asking the right questions, and being willing to be wrong about specifics while staying right about the direction. We did 300 manual switches before writing a line of automation code, because understanding the problem at that level of detail was more important than moving fast. If you understand the problem more deeply than anyone else in the room, that is your credential.
Quote: Most early-stage companies go to market too broad and wonder why nothing sticks. Companies go too wide to solve every problem. Narrow is how you find the wedge and build on it.
