Build vs buy vs partner. The infrastructure decision for licensed fintechs.

When a licensed fintech needs to build its product on top of banking infrastructure, the founders face a decision that is usually made on engineering bias rather than commercial logic. The default move for technically strong founders is to build. The default move for capital-constrained founders is to buy. The default move for founders who have done this before is to partner.

The decision is more nuanced than the defaults suggest. Different starting positions produce different correct answers, and the cost of getting it wrong is measured in years of delayed launch and capital burn.

I have seen all three paths execute well, and I have seen all three fail. The pattern of failure is not random: it correlates with mismatched decision logic and the founder’s starting position.

The build option

What it means: a fintech employs its own engineering team to develop the core stack (transaction processing, ledger, KYC orchestration, card processing integration, treasury management, reporting) from scratch or from open-source components.

When it wins.

When the product genuinely needs a custom architecture that no available platform supports. This is rarer than founders think. Most fintech products are variations on patterns that have been built before, and the actual differentiation is at the customer experience layer - not at the infrastructure layer.

When it loses.

When the build is justified by “we want to control our destiny” or “we don’t want to be dependent on a vendor.” These are emotional justifications, not commercial ones. A build that takes 18 months to reach production parity with a vendor’s offering has consumed 18 months of capital, 18 months of management attention, and 18 months of opportunity cost. Most fintechs that build die because they do not have 18 months.

How to test it.

Write down what you will be able to do six months after launch that you could not do if you bought. If the answer is “we will have built our own ledger,” that is not a customer-facing differentiator. If the answer is “we will have launched a product category that no platform supports,” that is.

The buy option

What it means: a fintech licenses a platform (BaaS orchestration, vertical SaaS for regulated institutions, embedded finance) that provides the core stack as a configured service. Fintech focuses its engineering team on the product layer above the platform.

When it wins.

When a fintech can ship a competitive product on the platform’s configuration without needing custom development. This is the modal case for most fintech products: payments, neo-banking, embedded finance, white-label cards.

When it loses.

When a fintech selects a platform that cannot actually deliver what the marketing copy promised. The licence is signed, the PS budget is exhausted, and the product is still six months from launch. This is the most common failure mode in the buy path, and it is preventable through the kind of vendor evaluation discipline that most buyers skip.

How to test it.

Can the vendor show you, in a working sandbox, the specific user flows your product needs, with realistic data and realistic latency? If yes, the platform will probably deliver. If the demo requires conditional language (“we can configure this for you” or “this will be in the next release”), the platform is selling promises - not capability.

The partner option

What it means: a fintech secures a direct commercial relationship with a banking partner (sponsor bank, issuing bank, EMI partner) and builds its own connectivity layer on top of that relationship, without an intermediating platform.

When it wins.

When a fintech has access to a partner relationship that produces commercial terms (interchange, FX margin, deposit revenue share) that meaningfully exceed what a platform can pass through. This usually requires either an existing relationship from a founder’s prior career, or specific commercial leverage the partner values.

When it loses.

When the partnership is assumed rather than contracted, or when the partner’s operational capability does not match the fintech’s launch timeline. The most expensive failure here is the partnership that exists on a handshake at the senior level but cannot execute at the operational level. Fintech spends months trying to integrate with a partner whose API is not production-ready, or whose internal compliance process introduces delays the founder did not anticipate.

How to test it.

Do you have a signed term sheet, a named integration lead at the partner with allocated capacity, and a launch date that the partner’s operations team has confirmed in writing? If any of these is missing, you have a partnership concept - not a partnership.

The decision sequence

The decision is rarely binary. Most successful licensed fintechs combine: they partner for one critical relationship (the banking sponsor, the card scheme membership), they buy for the orchestration layer, and they build only the customer-facing product.

I would run the sequence in this order:

1. Identify what you must build because no one else can build it for you. This is your differentiation.

2. Identify what you must partner for because the commercial value justifies the operational complexity. This is usually one or two key relationships.

3. Buy everything else.

Founders who reverse this sequence (build everything, partner for nothing, treat the platform as the differentiator) are the ones who burn capital fastest. The honest sequence forces a small build, a focused partner conversation, and a quick buy decision. The reverse sequence produces an indefinite build, a deferred partner conversation, and a buy decision that never gets made because the build always looks 60% done.

Common failure modes

Building because the CTO wants to.

The CTO’s enthusiasm is not a substitute for the commercial test. Build if the build differentiates the product. Do not build because building feels more credible than buying. This is the most common failure mode for technical founder teams in their first fintech.

Buying because the vendor pitch was good.

The pitch is the easy part. The hard part is execution at month 12 when the integration is half-complete and the PS budget is gone. Vendor evaluation discipline - asking the questions most buyers skip - is what protects against this. The previous essay on vendor evaluation covers the specific questions that matter.

Partnering because a senior banker said yes at dinner.

Senior bankers say yes a lot. Operations teams execute slowly. The gap between the senior conversation and the operational reality is where partnerships die. The signed term sheet, the named integration lead, and the written launch date are not formalities. They are the test of whether the partnership is real.

The right answer for most licensed fintechs in 2026 is a mix: build the product, buy the orchestration, partner for the banking. The fintechs that try to do all three of build, buy, and partner at the same time end up with the worst of each: a half-built stack, an over-customised platform, and a partnership that does not quite work. The discipline is choosing which layer is which, and being honest about the answer.