The pattern that repeats
A software platform launches embedded lending. The program works technically. Customers use it. Volume grows. And then, 12 to 18 months in, the economics don't look the way they were supposed to. Referral fees are smaller than projected. The platform doesn't own the customer relationship. Product evolution is limited by what the provider allows. The program is running, but it isn't building toward anything.
This pattern repeats with enough consistency to suggest it isn't bad luck. It's structural — the result of predictable decisions made in the wrong sequence. Here's what's actually causing it.
Root cause 1: The provider was selected before the model existed
The most common cause of underperforming embedded lending economics is also the simplest: a BNPL provider, capital marketplace, or lending API was integrated before the platform defined its lending model, economics requirements, or underwriting approach. The provider's commercial defaults — referral fee structure, underwriting criteria, servicing terms — became the program's economics by default.
Provider defaults are not negotiated in your favor. They reflect the provider's economics, not yours. Platforms that evaluate providers before defining their model accept those defaults. Platforms that define their model first negotiate against specific requirements — and get meaningfully better terms or choose better-fit providers.
The fix for existing programs isn't always straightforward. Renegotiating commercial terms mid-program is possible but expensive. Migrating to a different provider after integration is operationally disruptive. The earlier this decision gets revisited, the lower the cost of correction.
Root cause 2: The referral model was chosen without a migration path
Referral was the right starting point — fast to launch, low operational complexity, no risk exposure. The mistake wasn't choosing referral. The mistake was not designing the migration path to co-origination or a more economics-favorable structure before the referral program launched.
Referral economics are flat. The fee per origination doesn't improve with volume. As the platform scales, the gap between what referral generates and what co-origination would generate grows — but migrating from one to the other after the program is live requires renegotiating the provider relationship, potentially rebuilding the integration, and redesigning the operating model. All of which is harder under operational pressure.
Root cause 3: Payments and lending were designed as separate programs
The payments sponsor bank, compliance framework, and program model were established without accounting for lending. When lending was added, it required a separate bank relationship, a separate compliance framework, and a separate operating model — because the payments infrastructure wasn't designed to extend to lending.
This creates operational duplication, higher compliance overhead, and lost economics. The bank relationship that covers payments often has favorable interchange and float terms — but those economics don't extend to lending if the lending program sits with a different institution. The compliance investment made for payments doesn't transfer to lending. Every integration point between the two programs is a point of operational friction.
Platforms that designed payments and lending as a unified infrastructure from the start don't have this problem. For platforms that didn't, the fix is usually a program model redesign that consolidates the bank and compliance infrastructure — which is expensive but recoverable.
Root cause 4: Customer ownership was never defined
Many embedded lending programs launch without explicitly defining who owns the lending customer relationship. In referral models, the answer is almost always "the lender" — which means the lender can cross-sell, communicate directly, and deepen the relationship without the platform involved. This is often acceptable at launch. It becomes a strategic problem when the platform wants to build a financial services business and discovers its lending customers belong to the lender.
Customer ownership terms need to be explicit in the program agreement — not inferred from how the product happens to work. The platforms that retain customer ownership structure this deliberately in the original provider agreement. The ones that don't discover the limitation when they want to expand.
Root cause 5: The compliance and servicing model wasn't designed for scale
The compliance obligations that lending introduces — Regulation Z, state licensing, consumer protection, servicing requirements — are meaningfully different from payment compliance. Most platforms don't discover this until volume has grown to the point where the operational model starts to strain.
Dispute management, collections coordination, repayment processing, and servicing escalations are not handled by the lending API. They require an operational design that most platforms built informally at launch and never formalized. The result is an operations team handling lending servicing with processes designed for payment exceptions — which works until it doesn't.
The recovery path
For programs experiencing any of these patterns, the recovery sequence is consistent:
First, diagnose which root causes apply to your specific program. They rarely all apply simultaneously — and the economics recovery looks different depending on whether the primary issue is the referral model, the provider terms, the bank consolidation, or the operating model.
Second, prioritize by economic impact and reversibility. Some gaps — renegotiating commercial terms, consolidating bank relationships — are reversible but require relationship work. Others — customer ownership terms in existing contracts — may require waiting for contract renewal. Others — redesigning the operating model — can be done without touching the provider relationship.
Third, design the target state before starting any recovery work. Fixing the referral model without defining the co-origination structure you're migrating toward doesn't improve the outcome — it just changes the problem.
If your embedded lending program is running but not delivering the economics it should, we should talk. Or read about how ExpandUp approaches embedded lending restructuring.