How London fintech companies win their first bank customer

A London fintech wins its first bank customer by solving a problem that has an internal owner, proving that the gain justifies adoption risk, and making the product safe enough for the bank to operate. A pilot becomes contracted revenue only when both sides agree the production scope, controls, commercial terms and decision criteria before testing begins. Proximity to banks can create meetings, but evidence and risk ownership close the deal.

The founder should therefore sell two products at once: the customer outcome and the bank’s ability to govern the supplier. A compelling demonstration without security, resilience, data, compliance and implementation evidence can stall. A complete vendor pack without a senior sponsor and measurable business case can pass diligence and still never receive a budget.

This draft does not yet verify how three named London fintechs won a first bank customer, so it cannot present the sequence below as an observed London conversion formula. Until contracts, contemporaneous evidence and interviews are added, it is a regulator-grounded operating framework for testing a sales plan. A pilot, public partnership and paid production contract must remain separate evidence states.

Start with an owned problem, not a generic innovation pitch

Banks receive many proposals framed around artificial intelligence, open banking or automation. Technology is not the buying reason. The first task is to identify a costly or risky workflow with a named executive owner and an operational team that feels the problem.

The useful discovery questions are specific. Which customer or employee journey fails? How is the bank handling it now? What loss, delay, control weakness or cost does that create? Which budget owns the remedy? Which rule or policy constrains the solution? Who can authorise a trial, and who can stop it?

A founder should leave discovery with a testable outcome, not only positive feedback. Examples might include reducing manual reconciliation while preserving auditability, finding suspicious transactions without an unacceptable false-positive burden, or improving the clarity of customer communications. The metric must be paired with a guardrail so that speed or cost is not improved by shifting harm elsewhere.

Build a coalition before asking procurement to act

An innovation or product contact can open a door, but rarely controls the whole purchase. The supplier needs a business sponsor who owns the outcome, an operational user, a technical integration owner and early contact with risk functions. Compliance, legal, privacy, cyber security, model risk and procurement may join according to the product.

The coalition matters because a bank remains responsible for services it outsources. The FCA’s outsourcing guidance says regulated firms must manage third-party risks through the life of an arrangement and cannot delegate their regulatory responsibility. The PRA’s supervisory statement SS2/21 sets expectations for PRA-regulated firms on matters including due diligence, data security, business continuity and exit planning.

These obligations explain why a willing sponsor cannot simply wave a small supplier through. A founder who brings the relevant control owners into the design early can avoid discovering after the pilot that the intended architecture, subcontractor or data flow is unacceptable.

Prepare evidence before the vendor questionnaire arrives

The first bank deal often exposes gaps that smaller customers tolerated. The supplier should prepare a proportionate evidence room before formal diligence. Its contents will vary, but usually include corporate structure and finances, information-security governance, data flows, access controls, incident response, business continuity, disaster recovery, vulnerability management, subcontractors, insurance and an exit plan.

Claims should be supported rather than decorated with badges. A policy that no one follows is weak evidence. A certification can help but may not cover the exact service. The bank will care about who can access its data, where processing occurs, how changes are controlled, how incidents are reported and how service continues or exits if the fintech fails.

The FCA’s operational-resilience material requires in-scope firms to identify important business services and remain within impact tolerances. A supplier should be ready to explain which bank service it supports, likely failure modes, recovery objectives and dependencies. This turns resilience from a late questionnaire into part of product architecture.

Design a paid pilot that can convert

A pilot should answer the smallest commercially decisive question. It needs a defined environment, customer or data scope, baseline, target metrics, safeguards, timetable, named owners and a decision date. The contract should state what is paid, who bears implementation work, how data is handled, what happens at the end and what evidence permits production rollout.

Free pilots can be rational when the learning is genuinely valuable and the cost is tightly bounded. They become dangerous when the bank has no committed sponsor, procurement path or production budget. The fintech then subsidises open-ended experimentation while the customer avoids a decision.

Conversion terms need not fix every future price, but they should establish the commercial shape: licence or usage basis, expected scope, implementation responsibilities and the approvals still outstanding. A test with no path to a purchase order is a product experiment, not a sales stage.

Founders should also distinguish a technical proof from a live regulated service. Synthetic-data testing can establish feasibility without proving operational performance. A controlled live pilot can generate stronger evidence but demands tighter safeguards. A production contract requires the repeatable controls, support and service management that a one-off pilot may conceal.

Treat procurement as product work

Bank procurement is often described as delay imposed on a startup. A more useful view is that it reveals requirements in the real product. Contract provisions on audit, subcontracting, service levels, liability, data return, termination and regulatory access affect architecture and economics. They should be owned jointly by commercial, technical and risk leaders.

The supplier should maintain one answer set and evidence register rather than rebuilding responses for every stakeholder. Open issues need an owner and due date. Senior leaders should decide consciously which bespoke requests the company can support without turning the first customer into a unique code base.

The bank also has work to do. A serious customer supplies decision-makers, timely access, test data, integration support and a clear approval path. Founders should qualify the buyer by those contributions. Endless diligence with no internal resources or executive decision is a warning that the project is not sufficiently important.

A first customer is credible only when the evidence is precise

Announcements often blur partnership, pilot, supplier selection and production use. Founders should describe the stage accurately. Contracted revenue requires an executed commercial agreement and an obligation to pay, not an event appearance or memorandum of understanding. A referenceable customer has separately agreed what may be disclosed. A successful implementation means agreed outcomes were achieved in the relevant scope, not that the software ran once.

The strongest first customer creates three assets: revenue, product evidence and a reusable control package. It teaches the fintech which integration and governance work recur across banks. It can also expose an unattractive reality, such as services work that overwhelms subscription economics. The founder should measure implementation effort and ongoing support as carefully as contract value.

No authoritative public dataset gives a standard London bank-sales timeline. Any claim that banks buy within a fixed number of months should be treated sceptically unless the sample and definition are disclosed. The appropriate plan works backwards from the customer’s governance and budget cycle, then maintains enough runway for delays.

Limits of this playbook

Requirements differ by bank, jurisdiction, service materiality and data access. A tool used by a small internal team faces a different review from infrastructure supporting payments or credit decisions. FCA and PRA guidance explains the regulated customer’s responsibilities, but it does not publish individual procurement scoring or contract terms.

This draft has not yet met the content plan’s requirement for founder interviews, bank procurement perspectives and three independently checked first-customer examples. Those are publication gates. Each example must identify the legal entities, whether the work was paid, the production status and the evidence that the customer was genuinely first. Until they are added, the article should be read as a regulator-grounded operating framework, not a claim about average pilot duration, conversion rates or observed sales practice in London.