The decision to embed lending in a SaaS platform is not a single product decision — it is an architecture decision with implications that extend to the platform's regulatory position, balance sheet exposure, unit economics, and operational capability requirements. We have seen this decision made badly more often than well, usually because the platform team approached it as a feature build rather than a business model choice. The architecture question is: where does the credit risk sit, and what is the platform's actual role in the credit decision? The answer to that question determines almost everything else about the product design, the regulatory obligations, and the long-term economics.
The three main structural models are distinct. In the first — balance sheet lending — the platform holds the loans it originates on its own balance sheet, bears the credit risk directly, and earns the full net interest margin. This model delivers the highest economics per loan but requires regulatory authorisation (a consumer credit licence under the Financial Services and Markets Act 2000 for consumer lending, or equivalent coverage for B2B), requires significant capital to fund the loan book, and means the platform is directly exposed to credit losses if its underwriting model performs poorly. For an early-stage SaaS company, this is generally not the right starting point unless the team has deep credit portfolio management experience and access to debt capital at a cost that makes the net interest margin attractive.
The second model — originate and distribute — has the platform originate loans and immediately sell them to an institutional balance sheet provider (a bank, an ABS vehicle, or a specialist lending fund), retaining a servicing fee or an origination fee without holding the ongoing credit risk. This model reduces the capital requirement and the balance sheet exposure dramatically but introduces dependency on the institutional funding partner's credit appetite and pricing. In a credit tightening environment, a funding partner can reprice or reduce purchase capacity in ways that disrupt the platform's lending product more than its customers would accept. The risk here is counterparty dependency, not credit risk.
The third model — credit risk sharing — involves the platform retaining a subordinated first-loss tranche of the loan portfolio while a senior funder (bank or debt fund) provides the bulk of the capital. The platform's economic exposure is calibrated to the size of its first-loss position; it earns a share of the economics proportionate to its risk contribution. This model aligns incentives well — the platform has skin in the game on credit quality — but requires the platform to be comfortable with the accounting treatment of a contingent credit exposure on its balance sheet, and to maintain transparent dialogue with its funding partner about underwriting performance. For platforms with genuine informational advantage about their customers' creditworthiness, this is often the most attractive model once the loan book has accumulated enough performance data.
What we look for in embedded lending infrastructure is clarity about which model the company is building for and whether the technology architecture is designed appropriately. An infrastructure provider serving balance sheet lenders needs a different feature set than one serving the originate-and-distribute model: the former needs sophisticated loan servicing, forbearance management, and regulatory reporting; the latter needs efficient loan transfer mechanics, performance attribution, and funder reporting APIs. The infrastructure companies that try to serve all three models with a single product often produce one that serves none of them well. Architectural clarity about the target credit structure is a prerequisite for building infrastructure that is genuinely useful.