Five years and twelve investments into the fintech infrastructure thesis, the founder pattern that has repeatedly predicted success is clear enough that we can state it without hedging. It is not a personality profile — the founders we have backed have ranged from intensely technical to primarily commercial, from methodical to instinctive. What they share is a specific relationship with the financial system they are rebuilding: they have worked inside it, they understand where the friction is genuinely structural rather than cosmetic, and they have encountered enough of the real system's resistance to have lost any illusion that the solution is straightforward. This is what we mean when we say we back operators who have worked inside the system. It is not a credential requirement; it is an epistemic requirement.
The epistemic requirement manifests in how founders talk about the problem they are solving. The founder with genuine insider experience will describe the specific friction point in operational terms — the bank API that returns a 200 status code for a failed payment, the reconciliation process that breaks when a BACS direct debit reference is truncated, the compliance team review that blocks a product launch because the data model does not produce the audit trail the MLRO requires. These are specific, operational descriptions of real friction, not aggregated observations about market size or incumbent weakness. The founder without that experience describes the problem in terms of what the existing system fails to do for customers; the founder with it describes the specific mechanism by which the system fails and why that mechanism is hard to fix from the outside. The latter description is a much better predictor of whether the product they are building will actually solve the problem.
The commercial instinct we are looking for at seed stage is one oriented toward enterprise relationships rather than consumer metrics. Fintech infrastructure companies sell to enterprises — regulated financial institutions, SaaS platforms with existing customer relationships, professional services firms with payments needs. The sales motion is long, the evaluation is technical and commercial simultaneously, and the relationship that matters most in the first twelve months is often not with a procurement team but with a product or engineering counterpart who can champion the integration internally. Founders who have navigated enterprise sales in financial services — as a vendor, as a financial institution employee evaluating vendors, or as a professional working alongside that relationship — understand this intuitively. Those who have not tend to underestimate the time to first revenue and overestimate the pace of reference expansion.
We are not looking for a specific academic background, a specific prior employer, or a specific founding team size. We have backed solo founders and co-founding teams, technical founders and commercial-led teams, founders from large institutions and founders from early-stage companies. The constraint is not biographical — it is whether the specific combination of the founder's knowledge, the problem they are solving, and the architecture they are building makes a coherent story that we believe at a mechanical level, not just at a market size level. The founders who make us say "this is the right person building the right product at the right time" almost always have a specific insight — a single observation about the system they came from that nobody else has acted on yet — and a technical approach that makes that insight into a defensible product architecture. When we find both, we back them with conviction.
One profile that we consistently pass on, and are willing to name directly, is the founder whose primary insight is that an existing fintech product is badly designed and they can design it better. This is sometimes true — there are fintech products with genuinely poor design — but improved design is not, in general, a durable moat in financial infrastructure. The moat in financial infrastructure comes from data accretion, from network effects in payment flows, from regulatory standing that competitors cannot easily replicate, and from deep integration into enterprise workflows that generates switching costs. A better-designed product without one of these structural advantages will attract customers until a competitor with better design and one of the structural advantages arrives. We back infrastructure, not interface. The distinction is fundamental to the thesis we have been developing since 2019 and it informs every investment decision we make.