The sequence problem that costs lending programs their economics
Most software platforms approach embedded lending the same way they approach embedded payments: find the right vendor, sign the contract, integrate the API, launch. The speed-to-market logic is the same. And the economic consequences are the same — a program built around vendor defaults rather than a defined model.
The five decisions below need to exist before any provider conversation. Not because providers are adversarial — most aren't — but because their commercial defaults reflect their economics, not yours. And lending economics, once set by a provider agreement, are significantly harder to change than payment infrastructure.
Decision 1: What is your lending model?
Referral, co-origination, balance sheet, or hybrid. These aren't marketing terms — they're the structural choices that determine who owns the credit risk, who captures the economics, and what product flexibility you retain.
Referral: You send customers to a lender. You receive a referral fee. The lender owns the relationship, the risk, and the economics. Fast to launch, weak long-term position. The ceiling is the referral fee.
Co-origination: You participate in the credit decision and share in the economics. More operational complexity, meaningfully better economics, some risk exposure. The economics improve as volume scales — unlike referral, which stays flat.
Balance sheet: You fund the loans. Maximum economics, maximum risk, maximum operational complexity. Makes sense at significant volume with specific capital strategies. Wrong for most platforms at launch.
Hybrid: A staged approach — start with referral or co-origination, migrate toward balance sheet as volume and operational capability justify it. The transition path needs to be designed from the start, not improvised later.
Most platforms default to referral because it's fastest. That's often the right starting point. The mistake is not designing the migration path before you start.
Decision 2: What is your underwriting approach?
What data does your platform have that a standalone lender doesn't? Transaction history, payment behavior, cash flow patterns, customer tenure, workflow data — these are underwriting signals that platform-embedded lending can access and traditional lenders can't. If you don't design your underwriting approach to use this data, you've given away your primary competitive advantage in exchange for speed of launch.
The underwriting model also determines which providers can serve your program. A provider that uses only bureau data can't leverage your platform's behavioral signals. A provider built for platform-native underwriting can. Defining your approach before provider evaluation means you're selecting the provider that fits your model — not adapting your model to fit the provider.
Decision 3: How does lending interact with your payments infrastructure?
This is the question most platforms never ask — and the one with the most expensive consequences when ignored.
Your sponsor bank relationship, compliance framework, and program model were probably established for payments. Lending introduces meaningfully different compliance requirements — Regulation Z, state lending licenses, consumer protection obligations, servicing requirements — that need to be incorporated into the existing infrastructure or will require rebuilding it.
More specifically: the bank that sponsors your payment program may or may not be willing to sponsor your lending program. The compliance framework that governs your payment operations may or may not extend to lending. The operating model that works for payment exception handling is categorically different from what lending servicing requires.
Platforms that design payments and lending as a unified infrastructure make these decisions once. Platforms that design them separately discover the conflicts later — typically mid-build, when changing direction is expensive.
Decision 4: What are your economics requirements at scale?
Not "we want to make money on lending." Specifically: what take rate do you need at $10M in monthly originations? At $50M? What referral fee makes the program economically meaningful versus just a customer convenience feature? What does co-origination economics look like against your cost of capital?
These numbers need to exist before the first provider conversation — because providers will offer commercial packages, and you need to evaluate them against a defined standard rather than accepting the first offer that sounds reasonable. Lending economics that look attractive at $5M in originations often look disappointing at $50M, for the same structural reasons BaaS payment economics disappoint at scale.
Decision 5: What does your operating model need to handle?
Lending is not just approval APIs. Operationally successful lending programs require servicing coordination, collections strategy, dispute management, repayment handling, exception processing, and compliance operations that have no equivalent in payment programs. Most platforms discover this after launch — when the operational model designed for payment exceptions can't handle loan servicing at scale.
The operating model design — who owns what, at what volume, with what escalation path — needs to be documented before implementation, not assembled from whatever the provider includes in their standard package.
The timing question
These decisions feel premature when you're still evaluating whether to add lending at all. They feel urgent when a provider is waiting for your signature. The goal is to have them answered before the provider conversation — which means the right time to work through them is before the first demo, not during contract negotiation.
Platforms that have defined their lending model, underwriting approach, payments integration design, economics requirements, and operating model before talking to providers negotiate from a position of clarity. They can evaluate whether a provider's commercial terms fit their model. Platforms that haven't defined these things negotiate from a position of ignorance — and the provider's defaults fill the gap.
If you're evaluating embedded lending and want to work through these decisions before any provider conversation, we should talk. Or read about how ExpandUp approaches embedded lending architecture.