Devesh Sachdev joins GLAAS as co-founder & MD, invests $5 Mn Read more →
Embedded Finance

Should Your Platform Build Lending In-house or Bring in a Partner?

Platforms with merchants who need working capital between orders are sitting on something useful: they already have the relationship, the transaction data, and the touchpoint. What’s often missing is the capital and operating structure to deploy money against those assets.

The question that follows isn’t really “build or partner?” It’s this: which parts of the lending business does your platform want to own? Both paths are real and viable. The right choice depends on what your platform does and how central credit is to your core business.

A merchant who can access working capital through your platform has one less reason to look elsewhere for it. How you address that has consequences that shape your operations for years.

Key Takeaways 

  • The decision is about ownership, not just cost. Building lending in-house means taking on capital, underwriting, servicing, collections, and regulatory structure alongside your platform.
  • Not all partnerships are the same. A referral model and a genuinely embedded model have different data contributions, different merchant experiences, and different commercial outcomes.
  • Risk isn’t automatically the lender’s. Some partnership structures may include a Default Loss Guarantee (DLG), subject to the applicable regulatory framework. Know your exposure before the first loan is disbursed.
  • Platform data changes what underwriting can do. Bureau scores may miss signals already visible in your transaction, order, and payment records.
  • The right partner matters. So does the right structure.

What Building Lending In-House Actually Means

Building lending capability isn’t the same as shipping a product feature. “Building in-house” covers a wider range of choices than the phrase suggests, because the path depends on which regulatory and capital structure you pursue.

A platform that wants to deploy its own capital directly may need to operate through an appropriately regulated lending structure, depending on the exact approach and the applicable RBI framework. A platform that wants to retain substantial control over underwriting while working with an existing licensed lender would need to structure that arrangement appropriately under applicable guidelines. Both involve taking on parts of the credit business, but the regulatory requirements, capital commitments, and operational complexity differ considerably between them.

Across any path, the responsibilities to resolve include:

  • Capital: Money that has to be available to fund the loans.
  • Underwriting and credit risk: Models, data, and people to assess creditworthiness and manage portfolio health over time.
  • Loan servicing and collections: Systems to track repayments, and an operation for when merchants don’t pay. Collections isn’t a lightweight function.
  • Regulatory reporting: Ongoing obligations that run as long as the lending operation does.

Together, these look more like running a financial services business alongside your platform than adding a product feature. For most B2B marketplaces and supply-chain platforms, credit matters to their merchants but isn’t the platform’s core business.

What Partnering Actually Means, and Why Models Differ

In a partnership model, a regulated lender provides the capital and carries the lender-side regulatory responsibilities. Your platform provides the distribution and the data. From the merchant’s side, they’re accessing money through a screen they already know.

But “partnering with a lender” isn’t one thing.

In a referral model, your platform directs merchants to the lender’s own portal. You originate the referral, but the lender owns the application journey: the experience, the approval decisions, the outcome.

In an embedded lending model, the lender builds underwriting around your platform’s transaction data and the merchant-facing journey lives inside your product. The lender provides the regulated lending structure; the merchant journey can remain inside your platform, while your platform contributes the data.

What a platform typically owns in an embedded model:

  • The merchant interface: the offer, application, and disbursement confirmation sit within your product environment.
  • The data: transaction history, order patterns, and payment records the lender can draw on.
  • The commercial relationship: the merchant still knows your platform; the licensed lender is disclosed in the terms.
  • A clear operational dependency: the lender handles underwriting decisions, disbursement, and collections. How much control the platform retains over those functions depends on the partnership structure.

Build vs Partner: Who Owns What

The table below shows a typical responsibility split. How responsibilities are allocated in practice depends on the specific arrangement, applicable regulation, and negotiated terms.

ResponsibilityBuild (Typical)Embedded Partner (Typical)
CapitalPlatformLender
Credit risk / default exposurePlatformLender (may vary)
Lending regulatory responsibilityPlatformLender
UnderwritingPlatformLender (may draw on platform data)
Merchant-facing UXPlatformPlatform (subject to partnership terms)
Transaction dataPlatformPlatform
Servicing / collectionsPlatformLender (may vary)
Integration developmentPlatformPlatform + Lender

Some partnership structures may include a Default Loss Guarantee (DLG), subject to the applicable regulatory framework. In an embedded partnership, the platform is facilitating access to the lender’s product, not lending itself. That distinction matters commercially and from a regulatory standpoint.

When Building Makes Sense

Building makes sense in a narrow set of circumstances: enough credit volume to justify the setup, a regulatory and organisational structure ready to absorb ongoing obligations, and credit genuinely central to how your platform creates value, not a supporting feature.

The question to ask honestly is whether credit is your platform’s core business, or a capability your merchants need from their platform.

When Partnering Can Go Wrong

The case for partnering breaks down in a few situations.

If the partner’s underwriting is too conservative, they’ll decline merchants your platform knows are reliable. Your merchants still don’t get money; the rejection has just moved somewhere else.

If the merchant experience looks like a redirect to another portal, the value of embedding credit largely disappears. 

If the risk-sharing arrangement isn’t negotiated, legally structured, and documented before launch, you may carry exposure you didn’t anticipate. Some partnership structures may include a DLG. Know what you’re in.

Partnering can be the right path for many platforms. Choosing the wrong structure or partner creates most of the same problems as not partnering at all.

What to Evaluate in a Lending Partner

If you’re going the partnership route, structure matters more than brand name.

Underwriting and Data Use

Does the partner use your platform’s transaction data, or primarily bureau scores? Bureau data may not capture what’s already visible in your records: order frequency, payment consistency, purchase volumes over time. A well-structured embedded model can draw on both.

Risk-sharing and DLG Terms

Some structures involve no direct platform exposure. Others may include a Default Loss Guarantee (DLG), subject to the applicable regulatory framework. The specifics need to be negotiated, documented, and understood before the first loan goes out.

Disbursement Speed

After approval, how long before the merchant receives the money? For a merchant fulfilling an order already in the pipeline, the difference between approval and actual disbursement matters.

Integration Timeline

The gap between a basic co-branded journey and a native embedded integration can be significant. Ask for actual timelines from comparable integrations, not estimates.

Merchant Experience and Post-launch Operations

Does the journey feel like part of your platform, or a handoff? And understand how the lender handles collections and post-disbursement borrower management: it shapes what your merchants experience when things don’t go to plan.

How GLAAS is Structured

GLAAS is an embedded credit company. It works with B2B platforms, including textile marketplaces, distribution networks, and supply-chain operators, to offer working capital to their merchants without the platform funding the loans or running the credit business.

GLAAS operates through Gromor Finance, its own RBI-licensed NBFC. Gromor Finance handles underwriting, disbursement, and collections. The platform owns the merchant-facing interface and shares transaction data. The platform doesn’t fund the loans.

Where a merchant’s behaviour on a platform shows creditworthiness that bureau data alone wouldn’t capture, Gromor Finance draws on that transaction data in its underwriting.

On integration timelines: a co-branded, no-code journey can go live in under two days. A fully native embedded integration, built into the platform’s own product with a documented API and clear data-sharing agreed from the start, typically completes in under two weeks.

Since going live, ₹1,500 Cr+ has been disbursed across 110,000+ loans to 13,000+ MSMEs.

Get in touch: contact@glaas.co | +91 98336 69351

Frequently asked questions

1. Does a platform need regulatory approval to offer credit to its merchants?

In a partnership model, the lending is undertaken by the regulated lender. The platform facilitates access; it doesn’t deploy capital of its own. A platform that wanted to lend its own money would need to engage with the RBI on an appropriate regulated structure, the specifics of which depend on the type and scale of lending and the applicable regulatory category.

2. Who handles merchants who don’t repay?

In most partnership models, collections and recovery are the lender’s responsibility. Whether the platform carries any default exposure depends on the partnership structure and should be negotiated and documented before launch.

3. What does a well-constructed merchant experience look like?

The merchant applies through a screen that looks and feels like your platform’s product. Approval and disbursement notifications land in the same environment. The licensed lender is disclosed in the terms, but the experience doesn’t feel like a redirect. Keeping UX ownership requires explicit negotiation; it isn’t the default in every lender arrangement.

Written by
GLAAS Editorial Team
All articles →