Every bank and insurer has a list of things it wishes it offered but doesn’t. A current account provider without a competitive BNPL option. An insurer without a travel or gadget product. A high-street bank whose SME lending journey still routes customers to a branch. Building these capabilities in-house is slow, expensive, and increasingly hard to justify against a roadmap already stretched thin.

So incumbents buy in. Two models dominate that “buy” decision — embedded finance and white-labelling — and the two get conflated constantly, including by people selling both. They solve the same underlying problem (a gap in the product line-up) in structurally different ways, with different implications for who owns the customer, who carries the regulatory risk, and how the commercial deal gets priced. Understanding the distinction matters enormously if you’re a fintech trying to sell into a bank or insurer, because the two models call for different pitches, different contracts, and often different buyers within the same organisation.

Embedded finance: the bank’s journey, someone else’s engine

Embedded finance is when a regulated or specialist financial capability is woven directly into a bank or insurer’s own product journey, usually invisibly. The customer never leaves the bank’s app, never sees another brand, and in most cases has no idea a third party is involved at all. The bank owns the front end, the relationship, and typically the brand experience end-to-end; the fintech supplies the underlying capability through an API — payments infrastructure, BNPL underwriting, embedded insurance at the point of sale, KYC/fraud tooling, FX, or a lending decision engine.

Think of a high-street bank offering point-of-sale financing inside its own banking app, or an insurer selling embedded travel cover during a flight booking flow on a partner airline’s site. The bank or insurer is the shopfront; the fintech is the machinery in the back room.

The practical consequences of this structure:

• Customer relationship stays with the incumbent. Data, loyalty, cross-sell rights and the ongoing relationship sit with the bank or insurer.
• Regulatory responsibility depends on the structure. It may sit with one or more parties depending on the regulated activities being carried out, the permissions held and the contractual arrangements. Using a third-party provider does not remove the incumbent’s own regulatory obligations, including relevant requirements around outsourcing and operational resilience. Consumer Duty requirements may also be relevant where the arrangement forms part of the distribution chain for products or services within scope, with firms responsible for understanding their respective obligations and monitoring customer outcomes appropriately.
• Integration can be deep and technical. APIs may need to connect with existing core banking or policy administration systems, potentially resulting in substantial procurement, information-security and technology review requirements.
• Commercial models commonly include usage-based pricing, revenue share, per-transaction fees or interchange-style economics, although the structure varies by provider and arrangement.

White-labelling: someone else’s engine, badged as the bank’s own product

White-labelling flips the emphasis. Here the fintech has built a complete, functioning product — a current account, a card programme, a digital wallet, a comparison or claims-handling platform — and the bank or insurer licenses it wholesale, rebadges it, and sells it as their own. The underlying technology, and often the regulatory permissions, belong to the fintech or its regulated partner; the bank supplies brand, distribution, and customer base.

A classic example: a challenger bank’s savings marketplace technology being relaunched under a high-street brand’s own name, or an insurer’s travel insurance comparison tool actually being a rebadged version of a specialist provider’s platform. The customer believes they’re dealing with the bank throughout, but the product, the servicing, and often the regulatory permission sit with the fintech behind the curtain.

Practical consequences:

• Brand ownership sits with the bank or insurer, even though very little of the underlying product does.
• Speed to market can be considerably faster than building from scratch because the incumbent is taking a more complete product rather than developing the entire capability itself, although procurement, integration, compliance and operational-readiness requirements can still be substantial.
• The regulatory structure varies. The provider may hold relevant permissions itself, activities may be undertaken by another authorised entity, or an Appointed Representative or agency structure may be used where appropriate. In an AR arrangement, the authorised principal takes regulatory responsibility for the regulated activities carried on by the AR within the scope of its appointment. The chosen structure materially affects regulatory responsibilities, oversight requirements and contractual risk.
• Commercial structures may include a licence fee, revenue share, or a combination of the two. Longer-term contracts are also common where switching the underlying provider would involve significant operational work.

The difference in one line

Embedded finance typically involves a third-party capability being integrated into the incumbent’s own customer journey. White-labelling typically involves a more complete third-party product or service being offered under the incumbent’s brand. The boundaries can overlap, particularly with BaaS (“Banking-as-a-Service”) and modular platforms, so the commercial and regulatory substance of the arrangement matters more than the label attached to it. The structure can have important implications for customer relationships, regulatory responsibilities, data, commercial terms and the internal teams involved in procurement and oversight.

Why big institutions reach for either model

The trigger is almost always a gap analysis: a product line, a customer segment, or a journey the institution can’t profitably build itself, on a timeline that matters. A few recurring patterns:

• Speed pressure. A competitor has launched BNPL or embedded insurance and the institution needs something live within a quarter, not eighteen months.
• Niche or regulatory complexity that isn’t worth owning. Gadget insurance, crypto custody, or SME invoice finance are all technically demanding, low-volume-relative-to-core-business areas where owning the full stack doesn’t pay back the investment.
• Legacy core systems that can’t flex. Many tier-one banks are still running core banking platforms that make genuinely new product build painfully slow, so buying in a capability that plugs in via API is often the only realistic route.
• Testing appetite before committing capital. White-labelling in particular lets an institution pilot a new product line, prove demand, and decide later whether to build proprietary capability.

How fintechs should structure their offer to cover both options

The mistake many fintechs make is picking one commercial model and pitching it universally. Large banks and insurers have different buyers, different procurement paths, and different risk appetites for the two models — sometimes within the same organisation for different product lines. A fintech that can flex between “invisible infrastructure” and “branded finished product” from the same core technology is in a much stronger negotiating position. Some practical ways to build that flexibility in:

1. Build the product API-first, with the white-label front end as a separable layer

If the underlying engine — underwriting, ledger, claims logic, pricing — is cleanly decoupled from the interface, you can offer the same core capability as a pure API for embedded use, or hand over a themeable front end for white-label use, without maintaining two codebases.

2. Separate the regulatory permission conversation from the technology conversation early

Be explicit in pitch materials about the regulatory structure for each mode: which entity holds the relevant permissions, which entity carries out each regulated activity, and whether an Appointed Representative, agency or other arrangement is involved. In an AR structure, the authorised principal is responsible for the regulated activities carried on by the AR within the scope of its appointment. Clarifying this early helps the bank identify the compliance, risk, legal, product and engineering teams that need to be involved.

3. Offer a tiered commercial menu rather than a single pricing model

A menu spanning pure usage-based API pricing (embedded), a licence-plus-revenue-share model (white-label), and a hybrid — embedded infrastructure with an optional white-labelled servicing layer on top — lets procurement pick the model that matches their own risk and cost preferences without you having to redesign the deal from scratch.

4. Design your data and reporting layer so it works for both ownership models

Data access, servicing information and management information should be designed around the parties’ respective roles. Where Consumer Duty applies, the reporting layer should support the information-sharing and outcomes monitoring required by the parties’ respective obligations.

5. Position pilots as low-commitment entry points into either model

In some cases, a limited embedded pilot in a single journey can offer a lower-commitment entry point than a full white-label rollout. It can also help demonstrate the technology, operating model and customer proposition before either party commits to a broader deployment. A smaller embedded implementation can therefore become a route to a larger white-label or expanded partnership later.

6. Prepare separate materials for separate buyers

Procurement and IT security will want architecture diagrams, security certifications, and SLAs for an embedded deal. Compliance, risk, and the product owner will want permission structures, complaints-handling responsibility, and brand guidelines for a white-label deal. Trying to serve both audiences with one generic deck usually satisfies neither.