The seed-stage fintech landscape has a specific failure mode that is worth naming directly: the technically proficient team that has identified a genuine market gap but has never worked inside the financial institution they are trying to interface with. They can describe the problem — bank APIs are inconsistent, reconciliation is manual, credit decisioning is slow — but they have not experienced the specific friction points that make the existing system resistant to change. They have not sat in a bank's vendor onboarding process for eight months. They have not navigated a payments scheme's technical participation requirements. They have not had a compliance team ask them to rebuild a key product feature at 11pm before a launch. These experiences are not glamorous, but they are load-bearing. The founders who have had them build differently from those who have not.
The credential we weight most heavily at seed stage is direct operational experience inside the system being rebuilt. Not adjacent experience — not "I used to work in fintech VC" or "I consulted for banks on digital transformation" — but direct product or technical responsibility for the specific infrastructure the company is addressing. A payments startup founded by someone who built the real-time payment processing layer at a UK bank brings not just domain knowledge but relationships, regulatory vocabulary, and a clear-eyed view of the technical debt inside incumbent systems. That founder knows exactly which parts of the stack are genuinely hard to build and which merely appear complex from the outside. We look for that type of insider conviction.
The second criterion is what we call regulatory fluency rather than regulatory tolerance. There is a meaningful difference between a founder who views FCA oversight as a constraint to be managed and one who views it as an architecture input. The latter builds products where the compliance requirement is integrated into the data model from day one — where transaction monitoring, suspicious activity reporting, and customer due diligence are not bolted on before a Series A but are embedded in the system design at pre-seed. This is not about founders who enjoy compliance; it is about founders who understand that in financial services, the regulatory framework is as real a technical constraint as latency or database design. Ignoring it creates technical debt that compounds very quickly.
We are specifically not looking for the largest founding team or the most complete initial product. At seed stage, our preference is for two or three founders with complementary technical and commercial depth over a large team assembled before product-market fit. The infrastructure layer of financial services rewards depth over breadth at the early stage — the company that understands one specific bank API problem deeply and builds the best solution to it will earn trust faster than the one that promises to solve five things at once. We have passed on companies with impressive founding teams whose scope was so broad that we could not identify the specific infrastructure they intended to own. Clarity of surface area is a signal at seed that becomes harder to manufacture later.
On commercial traction, we expect something modest but deliberate at seed — not revenue, necessarily, but evidence that the problem exists in a form that generates commercial conversations. A letter of intent from a credible enterprise buyer, a pilot agreement with a financial institution, or a letter from a payment scheme indicating technical participation readiness are all meaningful. What we are less persuaded by is consumer traction for a B2B infrastructure product. Early-stage fintech infrastructure companies sometimes show consumer metrics because they are easier to acquire than enterprise relationships, but a thousand consumer signups for a B2B payments API tells us very little about whether the product will survive contact with a bank's procurement process. We weight enterprise signals heavily, even at the earliest stages.