GLAAS Blog

Author: GLAAS Editorial Team

  • How to Evaluate an NBFC Partner for Merchant Lending in India

    How to Evaluate an NBFC Partner for Merchant Lending in India

    Once a platform decides its merchants need working capital, the harder question isn’t whether to offer credit. It’s who to offer it with. Most prospective lending partners promise fast approvals and a seamless merchant experience. But the differences that matter aren’t always obvious from the initial pitch.

    An NBFC partner sits inside your merchant relationship for as long as the arrangement runs. The approval decision and the collections call are made by someone else, and your merchants experience both as part of your platform. You don’t need to be a lending expert to ask these questions, but you do need specific answers.

    Key Takeaways

    • Check registration and permitted lending activity against RBI’s list, then judge the lender on merchant-lending experience rather than size.
    • Get the credit policy in writing before launch. Platform data can help assess a thin-file merchant, but the lender decides.
    • Settle who funds the loans, who carries default risk, who sets pricing, how you are paid, and whether a Default Loss Guarantee applies.
    • Collections and reporting shape the merchant relationship after launch, so agree conduct, visibility and notice terms upfront.

    Is the NBFC Registered, and What Has It Lent?

    Ask for the Certificate of Registration number and check it against RBI’s list of registered NBFCs. Registration isn’t blanket permission: an NBFC is registered in a category and some activities need separate approval, so confirm the lending it proposes sits inside that category.

    An NBFC’s regulatory layer under RBI’s Scale Based Regulation framework reflects its size, activities and supervisory requirements. It doesn’t tell you whether the lender is right for your merchant profile. A large NBFC may have little appetite for small unsecured loans, while a smaller NBFC with proven experience in merchant lending may be the better operational fit.

    So ask how long it has lent to businesses like your merchants, in what ticket range, how that portfolio has performed, and who runs lending operations. If the journey runs through an app, check RBI’s Digital Lending Apps directory. A listing shows a lender reported it, not that RBI approves it. 

    Does the Lender’s Credit Policy Fit Your Merchants?

    A credit policy decides who gets through, and most friction comes from learning it one merchant at a time after launch.

    Get it in writing: business vintage and whether trading history on your platform counts towards it, turnover floors and ceilings, ticket sizes and how a limit is set, live states and cities, and what happens with a thin or absent bureau file.

    Then ask about data. A bureau score shows how a merchant has handled formal credit, not whether their orders have grown or invoices get paid on time. If your platform holds that history, ask whether the underwriting model can use it, and at what point in the decision. Transaction data can help a lender assess a merchant whose formal credit history is limited, but it doesn’t guarantee approvals, better pricing or larger limits. The lender sets its risk appetite and owns the decision.

    Who Funds, Who Carries the Risk, and Who Sets the Price?

    Funding and Risk 

    In most embedded arrangements the regulated NBFC funds the loan off its own book and carries the default risk, while your platform facilitates access and shares data under agreed permissions. Risk allocation can also be shaped by contract: some arrangements include a Default Loss Guarantee, where an eligible provider covers a defined share of losses on a named portfolio, subject to RBI requirements.

    Commercially, what matters is the 5% cap on cover against the amount disbursed from that portfolio, and the three permitted forms: cash with the lender, a fixed deposit under lien, or a bank guarantee in its favour. Under RBI’s rules, an NBFC may enter a DLG arrangement with an LSP or another lender acting as an LSP. 

    A platform can provide DLG only if it meets RBI’s eligibility requirements, including acting as an LSP in the arrangement and being incorporated as a company under the Companies Act, 2013. The rules are in Chapter III of RBI’s Non-Banking Financial Companies – Credit Facilities Directions, 2025, as amended. A DLG ties up cash or bank-guarantee capacity, so weigh it against the commercial return.

    Pricing and What You Earn 

    The lender is responsible for the rate and every charge a borrower pays, though the band and how risk tiers map to rates are negotiable. Where your platform acts as a lending service provider, its fees come from the lender, not the merchant, so ask how you get paid and whether it tracks volume or portfolio performance.

    Disbursement goes to the borrower’s own account and repayment directly to the lender, with narrow exceptions in the Directions. Routing merchant money through your platform isn’t one of them.

    What Does the Merchant Actually Go Through?

    Ask to walk the real merchant screens on a live or sandbox build.

    Settle where the journey runs and whose brand the merchant sees. It can be built natively into your product, co-branded, presented under your branding as a white-label flow, or completed on the lender’s hosted pages, and these overlap rather than being fixed categories.

    Then establish who owns each step: 

    • KYC collection and verification, and whether anything you hold can be reused
    • Whether credit decisions are automated or reviewed above a threshold
    • How the agreement and Key Fact Statement reach the merchant and get signed
    • How disbursement and repayment work when a mandate fails.

    Integration effort depends on the lender’s technology and your existing systems, so a published timeline means little on its own. Ask for numbers from completed integrations, including ones that ran long. Ask too what happens when a disbursement fails after approval: who notices, what the merchant is told, and whether a manual fallback has a named owner.

    What Happens When a Merchant Falls Behind?

    Some merchants will miss payments, and a collections call lands on a relationship you spent years building.

    Ask who makes contact and at what hours, whether collections are in-house or through an agency, what reminders a merchant gets before and after a due date, whether you are told too, and whether you can flag a merchant with a genuine dispute.

    Under the Credit Facilities Directions the lender must send a recovery agent’s particulars to the borrower before contact. The lender remains responsible for regulatory compliance, including the conduct of its LSPs. The arrangement must also provide borrowers with clear grievance-redressal channels and applicable escalation options. Regulatory accountability sits with the lender; the reputational effect can still land on you.

    What Do You Get After Launch?

    Ask what you will see after launch, and how often: applications, approvals, declines and disbursements; amounts outstanding and overdue; and what you need to reconcile your records against the lender’s. Sharing borrower-level information is governed by applicable regulatory and data-protection requirements, borrower consent and your contract, so agree which fields you receive before launch.

    Also agree on notice periods for changes to the lender’s credit policy or pauses in new lending, what happens to applications in progress and undrawn limits, and who communicates these changes to merchants. 

    How GLAAS Is Structured

    GLAAS brings together the technology, lending capital and operations needed for embedded merchant credit, including loan servicing and collections. Gromor Finance, its RBI-licensed NBFC, acts as the regulated lender and is responsible for credit decisions, loan funding and regulatory compliance.

    The partner platform continues to manage its merchant relationships and makes the credit offering available within its existing experience. Under the permissions and data-sharing terms agreed between the parties, its transaction history can feed into the underwriting. The exact division of responsibilities depends on the arrangement.

    A co-branded, no-code journey can go live in under 2 days and a fully native integration in under 2 weeks, with disbursement within hours of approval. GLAAS has disbursed ₹1,500 Cr+ across 110,000+ loans to 13,000+ MSMEs.

    If you’re comparing partners, these are the questions worth putting to us too. Get in touch now. 

    Frequently Asked Questions

    1. Who sets the interest rate a merchant pays?

    The lender is responsible for the rate and every charge on the loan. The band and how risk tiers map to rates stay negotiable within the partnership.

    2. What should a platform check before sharing merchant data with an NBFC?

    What your consent covers, which fields you share, where the data sits and for how long, and what the lender may use it for.

    3. What happens if the lender changes its credit policy?

    It can, because the policy is the lender’s. Negotiate the notice period, the treatment of applications in flight and undrawn limits, and who tells merchants.

    4. What happens to existing borrowers if the partnership ends?

    Disbursed loans stay the lender’s asset and the merchant’s obligation, running to their original terms. Wind-down terms are contractual, so agree them upfront.

  • GLAAS Expands Indore Office to Support Growing Team

    GLAAS Expands Indore Office to Support Growing Team

    We’ve moved our Indore branch to a larger office. The move supports a growing regional team, as we keep expanding our reach, both through GLAAS and our NBFC arm, Gromor Finance.

    We marked the move with a small celebration before settling into the new space.

    A Bigger Office for a Growing Team at GLAAS

    The larger space gives our Indore team room to grow as we support more credit activity across our platform and lending operations. Underwriting, servicing and collections all sit behind our technology, so a bigger team here means more capacity to serve merchants and dealers in and around the region, not just more desks.

    What We Do

    We’re a B2B embedded credit platform. We help digital platforms, including B2B marketplaces and supply chain operators, offer working capital to the merchants and dealers who sell or operate on them, without those platforms becoming lenders themselves. The regulated lending runs through Gromor Finance, our own licensed NBFC, while we handle the technology and operations behind the credit journey.

    Growth in Numbers

    We’ve disbursed ₹1,500 Cr+ to MSME borrowers, funded 110,000+ loans, and served 13,000+ MSMEs to date.

    None of this runs on technology alone. Seven in ten borrowers return for another loan, and each one still needs someone behind the process, whether that’s reviewing an application or chasing exceptions and repayments after approval. That’s exactly what a bigger regional office gives us more room to do.

    Why This Matters for Platforms and Merchants

    For platforms, embedded working capital is about more than adding another financial product. It gives merchants and dealers a way to fund orders without leaving the ecosystem they already use. That means the credit need doesn’t automatically send an existing merchant relationship to an outside lender. A stronger regional presence is part of how we make sure platforms and the merchants on them don’t have to find that out the hard way.

    Conclusion

    Our address in Indore has changed. Our mission hasn’t: getting small businesses access to credit through platforms they already use, while those platforms stay entirely out of the lending business. A bigger office is one more sign that we, along with Gromor Finance, plan to keep building on that, in Indore and beyond. Want to know how GLAAS could work with your platform? Get in touch. 

  • Who Bears Credit Risk in Embedded Lending Partnerships in India?

    Who Bears Credit Risk in Embedded Lending Partnerships in India?

    A platform considering embedded credit usually gets comfortable with the idea before it gets comfortable with the fine print. The idea is straightforward: merchants get working capital inside a screen they already use. The fine print question worth answering before any contract is signed is who actually stands behind a loan if a merchant doesn’t pay it back.

    The short answer is that in most structures, the regulated lender, usually an NBFC, carries that exposure, not the platform. The fuller answer depends on what the two sides agree to, and on a specific RBI framework that limits how much risk a platform can take on even if it wants to. The risk-sharing structure is agreed before the loans go live, not after a default happens.

    Key Takeaways

    • In a typical embedded lending partnership, the regulated NBFC funds the loan and carries the primary default risk, while the platform facilitates access and shares data.
    • A platform doesn’t automatically take on credit risk just by putting a lending product inside its interface.
    • Some partnerships include a Default Loss Guarantee (DLG), where an eligible Lending Service Provider, which could be the platform, agrees upfront to cover a defined share of losses.
    • RBI’s current digital-lending rules cap DLG cover at 5% of the amount actually disbursed out of the specific loan pool the guarantee applies to, not the platform’s entire loan book.
    • Whether a platform carries any default exposure, and how much, is a term to negotiate and document before launch, not a default outcome of embedding credit.

    Who Actually Makes the Loan?

    The regulated lender, usually an NBFC, is the lender of record: the entity whose balance sheet funds the loan, and whose name sits on the loan agreement. In most embedded structures, the credit journey itself sits inside the platform’s interface, but the regulated lender still has to be clearly identified to the borrower, and it’s the lender’s name that appears on the loan documentation. Since the lender is the lender of record, it also carries RBI’s regulatory and reporting obligations for that loan, including borrower disclosures and credit bureau reporting.

    A marketplace that puts a lending product inside its interface is facilitating access to credit, not extending it. That distinction decides whose balance sheet the loan sits on and who needs RBI’s lending licence, and it determines where the regulatory responsibility for the lending relationship sits. 

    It doesn’t mean the platform has no role at all: under RBI’s rules, a platform can be engaged as a Lending Service Provider (LSP), carrying out functions like customer acquisition, servicing or recovery on the lender’s behalf, while the regulatory responsibility and the licence requirement stay with the lender. A platform that wants to fund loans directly from its own books, rather than facilitate someone else’s, would need to operate through its own regulated lending structure, a different business than running a marketplace or a supply chain.

    What Is a Default Loss Guarantee (DLG), and When Does It Apply?

    DLG is the Reserve Bank of India’s term for a contractual arrangement where an eligible Lending Service Provider, sometimes the platform itself, sometimes another regulated entity acting as one, agrees to compensate the lender for a defined share of losses on a specific, earmarked pool of loans. The industry called the same mechanism FLDG (First Loss Default Guarantee) for years; DLG is the regulatory term RBI now uses.

    Not every platform can offer a DLG simply by agreeing to it. Under RBI’s current digital-lending framework, a lender can enter into a DLG arrangement only with an eligible Lending Service Provider, or another regulated entity acting in that capacity, and that LSP has to be incorporated as a company. The guarantee also isn’t written against the lender’s whole loan book: the lender earmarks a specific, fixed pool of loans covered by the DLG arrangement, called the DLG set, and the 5% cap runs against the amount actually disbursed out of that pool at any given time, not the pool’s full value. For example, if ₹10 crore has actually been disbursed from the DLG set, the maximum DLG cover at that point is ₹50 lakh. The guarantee has to be backed by cash deposited with the lender, a fixed deposit with a lien marked in the lender’s favor, or a bank guarantee.

    A DLG arrangement isn’t mandatory, and it isn’t automatic. Plenty of embedded lending partnerships run without one. Where one exists, it covers a defined slice of losses up to that 5% ceiling, and RBI requires the lender to invoke it within 120 days of a loan going overdue unless the borrower cures the default before then. None of this shifts the underwriting decision, the lending itself, or the lender’s regulatory responsibility onto the platform, and it doesn’t replace the lender’s own credit appraisal.

    How Should Risk-Sharing Terms Actually Get Negotiated?

    • The DLG set and the cap: Confirm which specific loans sit inside the guaranteed DLG set, since that pool is fixed once it’s earmarked, and get the cap stated in rupees: 5% of what’s disbursed out of that pool, not the platform’s full loan book.
    • The trigger: Where a DLG is invoked, it must happen within the prescribed 120-day overdue period unless the borrower cures the default before then; confirm whether the contract sets an earlier trigger within that window.
    • The form of the cover: RBI permits only cash deposited with the lender, a fixed deposit with a lien in the lender’s favor, or a bank guarantee. Confirm which permitted form the partnership will use. 
    • The tenor: The guarantee has to stay in force for at least as long as the longest-tenor loan inside that DLG set, so confirm what happens once that set matures and whether a new DLG set needs to be earmarked for the next cycle of loans.

    What Happens When a Merchant Misses a Payment?

    The regulated lender carries the regulatory responsibility for collections and recovery, since the loan is on its books and RBI’s reporting and grievance-redressal obligations attach to that lender regardless of who else is involved. In practice, the lender can engage a Lending Service Provider, which could be the platform itself, to carry out the actual servicing, follow-up or recovery work under a contract and the lender’s oversight, though the lender stays accountable for what that LSP does. Whether the platform carries any financial exposure through a DLG, and how that’s invoked, is a separate, negotiated question from who contacts the merchant or sends the notice. Both are worth confirming before launch, not after the first missed payment.

    How GLAAS Structures This

    GLAAS works with B2B platforms, including textile marketplaces, distribution networks and supply-chain operators, to put working capital in front of their merchants without the platform funding the loans or running the credit business itself. In these embedded-credit partnerships, GLAAS operates through Gromor Finance, its own RBI-licensed NBFC, as the regulated lender of record: Gromor Finance funds and underwrites the loans, carrying the regulatory responsibility that comes with doing so. GLAAS’s co-lending arrangements with banks and NBFCs sit outside this piece and follow a different structure.

    Risk-sharing terms, including whether a DLG applies and on what terms, are structured per partnership and set out in the underlying agreement rather than fixed across every platform GLAAS works with. Since launch, GLAAS has disbursed ₹1,500 Cr+ across 110,000+ loans to 13,000+ MSMEs.

    If you want the specific terms for your platform rather than the general shape of them, that’s worth a direct conversation. Get in touch with us. 

    Frequently Asked Questions

    1. Does my platform need to become an NBFC to share in credit risk through a DLG? 

    No. A DLG arrangement doesn’t require the guarantor to hold a lending licence. It does require the guarantor to be an eligible Lending Service Provider, incorporated as a company, or another regulated entity acting in that capacity. The entity extending the loan still needs to be a regulated lender, such as an NBFC or bank.

    2. What’s the difference between DLG and FLDG? 

    They refer to the same mechanism. FLDG (First Loss Default Guarantee) is the older industry term. RBI formally uses DLG (Default Loss Guarantee) for the regulated framework.

    3. Does a DLG mean the platform is underwriting the loans? 

    No. A DLG is a loss-sharing guarantee, not an underwriting arrangement. The regulated lender still has to carry out its own credit appraisal on every loan, and RBI’s rules specifically bar a DLG from substituting for that. The guarantee changes who absorbs a defined share of the loss if a loan goes bad; it doesn’t change who decided to approve the loan in the first place.

    4. Is there a limit on how much risk a platform can guarantee? 

    Yes. Under current RBI rules, DLG cover is capped at 5% of the amount actually disbursed out of the specific pool of loans the guarantee applies to (the DLG set), not 5% of a platform’s entire loan book, regardless of what the two parties might privately agree to.

    5. Who contacts a merchant if they miss a repayment? 

    In most structures, the regulated lender carries the regulatory responsibility for collections and recovery, but it can engage a Lending Service Provider, which may be the platform itself, to carry out that work day to day under its oversight. The exact division of responsibility depends on the partnership agreement and is worth confirming before launch.

  • How Long Does It Actually Take to Add Credit to Your Platform?

    How Long Does It Actually Take to Add Credit to Your Platform?

    If you’re considering embedded credit, implementation time is usually one of the first practical questions: how quickly could this actually go live?

    A co-branded no-code journey can go live in under 2 days. A fully native integration, where the credit experience is built inside your product, typically completes under 2 weeks.

    The gap between those two paths, in effort and in what the merchant actually experiences, is wide enough to matter.

    Key Takeaways

    • A no-code co-branded journey can go live in under 2 days. A fully native integration, built inside your product, typically completes in under 2 weeks.
    • Data preparation, internal approvals, and experience design decisions can extend the overall timeline before and during the build.
    • Platform transaction data can add underwriting signals that a bureau score alone may not capture.
    • What goes live first is a working version. Once live, the platform has real usage data to refine the credit offer over time.
    • After a merchant is approved, disbursement happens within hours.

    What are the Different Integration Options?

    Integration pathPlatform engineeringTypical GLAAS timelineExperience
    Co-branded no-codeMinimalUnder 2 days. Hosted/co-branded journey.
    Native APIRequiredUnder 2 weeks.Credit journey inside the platform.
    Custom/hybridDepends on scopeDepends on requirements.Mix of native and hosted components. 

    Embedded credit is not a single thing. At one end is a co-branded no-code journey, hosted and managed by the lending partner but visually consistent with your platform. Your team configures when and how the offer appears to merchants; the lender handles the lending process behind it. This can go live in under 2 days, with no API work on your side.

    At the other end is a native integration, where the credit offer, application, status updates, and disbursement notifications are all built inside your product using the lender’s API. The merchant can complete the credit journey without leaving your platform. A fully native integration typically completes in under 2 weeks.

    In between are various levels of customisation, from co-branded journeys with heavier UI work to partial API integrations that handle some parts natively and some through the hosted journey. Where you land depends on how central you want the credit experience to be inside your platform and how much engineering capacity you can put towards it.

    Where Does Time Go in a Native Integration?

    For teams planning a native build, a few things can extend the timeline beyond the engineering itself.

    Data Readiness

    The lending partner needs to assess your merchants to underwrite them. Platform transaction data, payment history, and order patterns can add underwriting signals that a bureau score alone may not capture, such as transaction frequency, order regularity, and payment behaviour over time. For that data to be useful, it needs to be in a form the lender can work with. If it sits across multiple tables, has missing timestamps, or was structured for an internal reporting tool rather than external sharing, preparation can add real time before the build begins.

    Internal Approvals

    A project that touches merchant data, the payment experience, and how your platform communicates with users may need sign-off from more than one team. Product, legal, and sometimes finance all have a view. Getting that alignment in place can extend the timeline, not because teams disagree, but because the question is often being formally put for the first time.

    Experience Design

    When and how you show the credit offer to a merchant matters. An offer shown at the wrong point in the journey, or framed poorly, can affect how merchants engage with it. Getting the framing right takes thinking time that the engineering estimate doesn’t always include.

    What Happens After You Go Live?

    Launch is not the finish line, though it tends to feel like one. What ships first is a working credit journey. Once live, the platform has real data to work with: 

    • Which merchant segments engage with the offer. 
    • Where in the purchase journey the offer lands best. 
    • What repayment behaviour looks like. 
    • Where merchants drop out of the application. 

    That data makes it possible to refine offer placement, merchant targeting, messaging, and the application journey itself. Disbursement, once a merchant is approved, happens within hours.

    What is the Platform Actually Building?

    Worth being clear on before scoping: the platform is not building a lending product. It’s building the merchant experience that sits in front of a lending product someone else runs.

    In a native integration, your engineering team connects to a partner API, your product team designs the screens, and you decide when and how to surface the credit offer. In the no-code path, the hosted journey handles the screens; your team configures the offer entry point and the branding. In both cases, the lender handles underwriting decisions, capital deployment, and collections.

    That’s a meaningful distinction when scoping the project, because the lending-specific logic is not yours to build or maintain.

    How GLAAS Works

    Platforms that want to offer their merchants working capital can work with GLAAS. The co-branded no-code journey goes live in under 2 days. A fully native API integration, where the credit experience is built inside your product, typically completes in under 2 weeks. Merchants receive disbursement within hours of approval.

    GLAAS operates through Gromor Finance, its RBI-licensed NBFC. The platform controls how credit is surfaced to its merchants; GLAAS handles underwriting, disbursement, and collections. Since launch, ₹1,500 Cr+ has been disbursed across 110,000+ loans to 13,000+ MSMEs, with a 70% repeat loan rate.

    If your platform is at the point of asking how long this takes, the next step is a short conversation with the GLAAS team. Get in touch: contact@glaas.co or 98336 69351.

    Frequently Asked Questions

    1. Can a platform go live with embedded credit in under a week?

    Yes, for a co-branded no-code journey. The lending partner provides the hosted journey; your team configures the offer and connects the entry point in your interface. This path is designed for platforms that want to launch without committing engineering resources to a full native build. Under 2 days is the realistic timeline for this option.

    2. Who builds the merchant-facing screens in a native integration?

    Your product team builds them against the lender’s API. The lender provides documentation and a sandbox for testing. The design decisions, when the offer appears, how it’s framed, and what the status updates say, are yours to make and iterate on after launch. For the co-branded no-code path, the hosted journey provides the screens; your team configures the offer rather than building the interface.

    3. What merchant data does the lender typically need before going live?

    Transaction history is an important input: how much a merchant transacts on the platform, how regularly, and whether their payment behaviour has been consistent. Cleaner, well-structured data is easier to use in underwriting.

    4. What is GLAAS and who does it work with?

    GLAAS provides embedded credit infrastructure that enables B2B platforms (marketplaces, distribution networks, supply-chain anchors) to offer their merchants working capital without holding the loans on their own books. GLAAS operates through Gromor Finance, an RBI-licensed NBFC, which handles the regulated side of the credit business. More than 13,000 MSMEs have been funded since launch, across multiple sectors.

    5. Does a platform need a lending licence for the integration?

    The platform does not need to become an NBFC to offer credit through this model. The lending licence sits with Gromor Finance. The platform’s exact responsibilities depend on the programme and integration structure.

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

    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.

  • What Is Embedded Credit Infrastructure, and How Is It Different From a Lending API?

    What Is Embedded Credit Infrastructure, and How Is It Different From a Lending API?

    Embedded credit ≠ Lending API.  Some providers use these two terms interchangeably. They don’t mean the same thing.

    A lending API is the connection between your platform and a lender’s system. Embedded credit infrastructure is everything required to run a credit product around that connection.

    That distinction comes down to 4 things: who decides which merchants qualify, what credit product they receive, who the licensed lender is, and who manages the merchant journey after disbursement.

    Merchants on B2B platforms need working capital between orders. When a platform doesn’t offer it, they find it elsewhere. That outside financial relationship gradually pulls engagement away. The distinction between a lending API and embedded credit infrastructure determines how much of that credit product a platform actually controls.

    Key Takeaways

    • A lending API is a data connection between your platform and a lender’s system. It sends application data and returns a result.
    • Embedded credit infrastructure is the broader setup around that connection. It can cover underwriting, product configuration, a licensed lending entity, the merchant-facing experience, and what happens after disbursement.
    • The practical difference is who handles what: who makes the credit decision, who sets the product terms, where the merchant applies and repays, and who manages collections.
    • The word “API” describes a connection method, nothing more. It tells you nothing about how the provider underwrites, what product they offer, or what happens once a loan is disbursed.

    What Does a Lending API Do?

    A lending API is a software connection between your platform and a lender’s loan origination system. When a merchant applies for credit, your platform sends their application data through the API. The lender’s system processes it and returns a result: approved, declined, or flagged for manual review.

    Data moves between the two systems without the platform needing to build its own origination system. The API doesn’t determine how the lender makes the credit decision, what product they offer, where the merchant completes the application, or who handles collections after disbursement. Those depend on the lender or provider, and they vary significantly from one provider to the next.

    Some platforms find this sufficient when the goal is connecting merchants to external funding. Others need more control over underwriting, product design, merchant experience, or post-disbursement operations.

    What Does Embedded Credit Infrastructure Actually Add?

    Embedded credit infrastructure is the assembled setup that lets a platform offer credit as a native product, without building an underwriting team, holding a balance sheet, or applying for a lending licence.

    The API is one component. 4 decisions determine everything else: who underwrites, what product gets offered, who the licensed lender is, and who manages repayment. Here’s what each one involves.

    1. Who Decides Which Merchants Qualify?

    In a properly built embedded model, the underwriting engine can incorporate transaction data from the platform itself: a merchant’s order volumes, payment behaviour, months of active trading, average basket size. If a merchant has bought and paid reliably on your platform for two years, that trading history is useful credit information even if their bureau file is thin.

    Bureau data and platform data work together rather than replacing each other. For platforms where many merchants are first-time formal borrowers, the ability to incorporate platform signals changes who qualifies.

    2. What Credit Product Can be Offered?

    A textile marketplace and a pharmaceutical distributor have different cash-flow cycles and very different borrowing needs. A configurable product setup means loan amounts, tenors, and repayment structures can be set to match the platform’s specific merchant base, rather than applying one standard product across all borrowers.

    3. Who Actually Lends the Money?

    Credit disbursement in India requires a licensed bank or RBI-registered NBFC to release funds. In a full embedded setup, the licensed lender is already part of the arrangement, either as an entity the provider owns or through a partnered bank or NBFC. The platform does not need to become a lender itself.

    4. Who Manages the Merchant Journey and Repayment?

      In an embedded setup, the merchant’s experience, from application through repayment, can stay inside the platform. Collections, repayment tracking, and delinquency monitoring are the provider’s responsibility. The platform gets visibility through a dashboard rather than inheriting the operational load.

      Embedded Credit Infrastructure vs a Lending API: How The Two Compare

      Standard API arrangementFull Embedded Credit Setup
      Credit decisionUsually controlled by the lenderCan incorporate platform data and configurable underwriting
      Credit productOften lender-ledCan be configured around the platform’s merchant base
      Merchant experienceMay redirect or use a co-branded flowCan remain inside the platform
      Licensed lenderMay need a separate lender relationshipIncluded in the overall setup
      Post-disbursementUsually lender-ledCan include platform visibility, monitoring and lifecycle support

      Why the Difference Matters in Practice

      Embedded Credit vs Lending API

      Approval Coverage

      A lender that relies heavily on bureau data may struggle to assess merchants with limited formal borrowing history, even if those merchants have traded reliably on your platform for years. An underwriting model that incorporates platform signals changes who qualifies.

      Merchant Experience

      Under a standard API arrangement, the merchant is redirected to the lender’s interface to complete the application and manage repayment. Under a fully embedded setup, the merchant can complete the credit journey without leaving your platform, while the regulated lending remains with the licensed lender.

      Product Fit

      A working capital loan structured for a twelve-week textile sourcing cycle won’t serve a dealer who needs a six-month equipment financing arrangement. Configurable product terms, set in collaboration with the provider, mean the credit product fits how the platform’s merchants actually trade.

      Visibility After Disbursement

      Under a standard API setup, collections belong to the lender and the platform has limited sight of which merchants are struggling until it shows up in their trading behaviour. A full embedded setup can also give the platform ongoing visibility through portfolio dashboards, repayment monitoring and early-warning signals on at-risk accounts.

      For more on how the regulatory side of embedded credit works for platforms, see our piece on finding the right lending partner for embedded finance. 

      How GLAAS is Set Up

      Here’s how GLAAS’s model works.

      • Credit decision: GLAAS’s underwriting engine incorporates platform transaction data alongside bureau data, helping assess merchants with limited formal borrowing history using a broader set of signals.
      • Credit product: GLAAS offers 25+ configurable credit products. Loan amounts, tenors, and repayment structures can be tuned to a platform’s merchant base rather than applied uniformly.
      • Merchant experience: GLAAS supports white-label and native journeys so merchants apply and repay without leaving the platform.
      • Licensed lender: GLAAS operates through Gromor Finance, its RBI-licensed NBFC. Platforms integrating with GLAAS don’t need their own lending licence or capital commitment.
      • Post-disbursement: Collections, repayment monitoring, and portfolio reporting run through GLAAS, with live dashboard access for the platform.

      GLAAS has funded 110,000 loans to 13,000+ MSMEs served across India. Seven in ten return for another loan. A co-branded setup goes live in under 2 days; a fully native integration in under 2 weeks.

      Evaluating how to add credit to your platform? Talk to GLAAS →

      Frequently asked questions

      1. Is a lending API the same as embedded credit?

      No. A lending API is a data connection: it sends a merchant’s application to a lender and returns a result. Embedded credit is the broader setup around that connection, covering underwriting, product configuration, the merchant journey, and what runs after disbursement. The API is one component inside a full embedded credit setup.

      2. Does a platform need its own NBFC licence to offer credit to its merchants?

      No. In an embedded model, the platform facilitates access to credit; it doesn’t lend. Lending is done by a licensed bank or RBI-registered NBFC that is part of, or partnered with, the provider. GLAAS operates through Gromor Finance, its own licensed NBFC, so platforms integrating with GLAAS don’t need to source a lender separately.

      3. How does platform transaction data improve credit decisions?

      Bureau data reflects a merchant’s formal borrowing history. Platform data reflects how they actually trade: order volumes, payment reliability, months of active trading. For merchants with thin bureau files who trade reliably on a digital platform, incorporating platform data can change whether they qualify.

      4. What happens to collections and repayments under an embedded credit model?

      The licensed lending entity manages collections. In a full embedded setup, the provider can also run post-disbursement monitoring, repayment tracking, and early warning on at-risk accounts. The platform has visibility through a dashboard but doesn’t run the collections operation.

      5. What does GLAAS provide, and who is the regulated entity?

      GLAAS is an embedded credit infrastructure provider for B2B digital platforms in India. It brings underwriting technology that incorporates platform transaction data, 25+ configurable credit products, a merchant experience that can stay inside the platform, and lifecycle management after disbursement. The regulated lending entity is Gromor Finance, an RBI-licensed NBFC owned and operated by GLAAS.

    1. How Does an Embedded Lending API Work for a B2B Platform in India?

      How Does an Embedded Lending API Work for a B2B Platform in India?

      A seller on your platform who needs money between orders will look for it. Ensuring they can find it without leaving your platform is the problem an embedded lending API is built to solve.

      It connects your platform to a licensed lender’s systems, so a seller can request working capital, receive a decision, and have money in their account without going elsewhere. A regulated lender does the actual lending. The API puts that product where sellers already manage their orders.

      Key Takeaways

      • Where the seller has consented, the platform sends their transaction data to the lender’s system. The lender uses it to generate an eligibility assessment or preliminary offer.
      • The seller expresses interest in the preliminary offer and completes any required identity checks. The lender runs underwriting and, on approval, provides the seller with the final terms and a Key Fact Statement inside the platform.
      • The seller reviews the final terms, accepts, and signs. The lender then disburses directly to their bank account; the platform’s account doesn’t sit in the middle.
      • Status updates flow back to the platform through the same API connection, keeping the seller’s loan state visible throughout.
      • Two integration routes: a co-branded option with no platform-side engineering build, live in about days; a fully native white-label option using REST API and webhooks, around a few weeks.

      What an Embedded Lending API Actually Connects

      Two systems that would otherwise sit apart: your platform, where sellers operate every day, and the lender’s systems, where underwriting, KYC, loan documentation, and disbursement happen. The API connects them.

      Where a seller has given prior, explicit consent for their platform data to be shared with the lender, the platform sends that transaction history to the lending system. The lending system uses it to produce an eligibility assessment or preliminary offer. That preliminary offer is not a loan approval. Final approval is a separate step, one that follows the seller completing any required verification and formally accepting the offer. Once that sequence is complete, the money reaches the seller’s bank account and status comes back to your platform.

      The result is that the seller handles the whole process inside the platform they’re already using.

      Who lends the money and what the platform’s regulatory position looks like in this arrangement is covered in Can a B2B Marketplace Offer Loans to Its Sellers Without an NBFC Licence? This article focuses on the API exchange itself.

      How a Revolving Credit Line Looks to the Seller

      The following is an illustrative example of how a revolving credit line works in this kind of integration, based on the seller journey GLAAS documents for this product type. Specific steps, timelines, and required seller actions vary by product, lender, and integration setup.

      A seller logs into their dashboard on the platform. A preliminary credit offer is already visible, based on an eligibility assessment run against their transaction history. This isn’t a loan approval; it shows the seller they’re likely eligible and gives them a sense of the available limit.

      The seller expresses interest. They see the lender’s identity and the preliminary loan terms before doing anything further. They’re then asked to complete identity verification, which may involve reviewing pre-filled details or providing additional information. This runs through GLAAS’s systems via the API; the platform team doesn’t handle or process it.

      Once verification is complete, the seller receives the final approved terms and a Key Fact Statement summarising the loan. They formally accept, e-sign the loan documents, and choose how much to draw and on which repayment plan.

      Money arrives in their bank account from the lender. Repayments run over the agreed schedule, managed through the lender’s systems. As they repay, the available limit refreshes for the next draw.

      What the Platform Sends, and What Comes Back

      How Does Underwriting Work Without the Platform Doing Any of It

      The central input the platform provides is the seller’s transaction history: GMV over time, how often they transact, their settlement patterns, how long they’ve been active. This is data the lending system doesn’t have independently, shared subject to the seller’s prior consent.

      A bureau score reflects a seller’s borrowing history. Platform transaction data can help the lender assess how that business actually operates today. Incorporating this alongside bureau and other checks can produce a more relevant view of a seller’s credit profile than bureau data alone, though how much weight it carries is a function of the lender’s underwriting policy. Pricing may also reflect that data, depending on how the lender has configured its model for the platform.

      What the API carries back:

      • A preliminary eligibility result, used to populate an offer visible in the seller’s dashboard.
      • The lender’s credit decision and final approved terms, along with a Key Fact Statement, once the seller has completed verification.
      • Status confirmation once the seller accepts and signs.
      • Status updates as the loan moves through disbursal and repayment.

      Separately, the platform’s operations team has access to a portfolio dashboard: a real-time view of active loans, repayment rates, and early signals on the book. This is a different interface from the per-seller API responses that drive the seller’s journey through the product.

      The platform team doesn’t build the credit model or manage individual accounts. That sits with the lender and its systems.

      The Lender’s Role: Offer, Approval, and Disbursal

      The offer appears inside the platform’s product, under the platform’s brand or co-branded depending on the integration route. Before the seller accepts anything, they see the lender’s identity and the key loan terms, along with a Key Fact Statement.

      Funds flow directly from the licensed lender to the seller’s bank account. Under RBI’s NBFC Credit Facilities Directions, 2025, disbursement must move from the regulated entity to the borrower, not through the platform’s account. Where a co-lending arrangement is in place, the loan documents identify the applicable lenders and their respective roles. The loan agreement is with the lender or co-lenders identified in the loan documents, never the platform. 

      Whether the platform carries any first-loss exposure depends on its specific role in the arrangement, applicable regulatory limits, and the terms of the agreement it has signed. This involves regulatory requirements and the platform’s eligibility to take that position, not just a commercial negotiation. 

      Post-disbursal, collections, repayment tracking, and loan servicing are managed by GLAAS on behalf of the lending partner. The platform team doesn’t run that operation.

      What Your Platform Needs to Build

      How much your team builds, and how long it takes, depends on which route you choose. The distinction matters: the native route requires the platform to integrate with GLAAS’s API; the no-code route uses GLAAS’s infrastructure without any platform-side API build.

      Co-branded, no-code

      There’s no platform-side engineering build under this route. The provider sets up the seller-facing journey, which runs within the platform’s product with no redirects to an external site. The experience carries a “Powered by GLAAS” co-brand mark. Setup and operational coordination between the platform and the provider still happen before launch, but the platform’s technical team doesn’t build or integrate anything. KYC, loan documentation, servicing, and collections are handled on the provider’s side. A platform can be live in under 2 days under this route.

      Fully native (white-label)

      The platform connects using the provider’s REST API and webhooks. SDK options are available for iOS, Android, and web. Integration starts in a dedicated sandbox environment; the platform tests the full seller journey before moving to production. Under this route, the seller sees only the platform’s own brand and UX throughout. Going live takes under 2 weeks.

      In both cases, the provider manages the underwriting model, KYC workflows, loan documentation, disbursement, collections, and post-loan servicing. The platform’s team doesn’t build or staff any of that.

      The choice between routes comes down to speed versus control over the seller-facing interface. The no-code option gets credit in front of sellers faster. The native route takes longer but gives the platform full ownership of how the product appears to sellers.

      Choosing the Right Integration Route

      The API turns a licensing arrangement into something a seller can actually use. It carries the seller’s transaction data to the lender’s systems, surfaces the decision and offer in the seller’s dashboard, and carries status updates back to the platform. The lender handles disbursement directly to the seller’s bank account, typically within hours of approval.

      Platforms like Razorpay and Meesho have built this into their merchant products. If you want to see what it would look like on your own platform, contact us and we’ll map which route fits your current setup.

      Frequently Asked Questions

      1. Does the platform need its own lending licence to use an embedded lending API?

      No. The licensed NBFC or co-lending partner handles the lending. The platform operates under that arrangement without needing its own licence or balance sheet. 

      2. Does the seller stay inside the platform throughout?

      Yes, under both routes. The co-branded journey runs within the platform’s product with a “Powered by GLAAS” mark. The native integration shows only the platform’s own brand and UX. There are no redirects to an external site in either case.

      3. What platform data is used for underwriting?

      The credit rule engine incorporates the platform’s own transaction data where available and with the seller’s consent: GMV history, settlement patterns, order frequency, and how long the seller has been active. This feeds the underwriting model alongside bureau data. How it is weighted in the final decision depends on the lender’s underwriting policy and the platform’s specific setup.

      4. What does GLAAS do and how is it regulated?

      GLAAS provides the embedded lending API and the credit technology behind it: underwriting systems, KYC workflows, collection management, and loan lifecycle monitoring. The licensed lender in each arrangement, which may be Gromor Finance or a co-lending partner, is the regulated entity that underwrites and disburses. GLAAS has disbursed ₹1,500 Cr+ across 110,000 loans to 13,000+ MSME borrowers, with seven in ten borrowers returning for another loan.

    2. Who Is the Lender When a Platform Offers Credit to Its Sellers?

      Who Is the Lender When a Platform Offers Credit to Its Sellers?

      A platform introducing a seller-credit offering inside its existing app needs one question answered before it goes live: when a seller borrows through that offering, who are they really borrowing from?

      If the arrangement is set up the standard way, a licensed NBFC is the lender, not the platform. The NBFC approves the loan, disburses it, and carries the risk if the seller doesn’t repay. The platform’s job is to bring the offering to sellers inside its own app and support the NBFC’s process, typically by supplying transaction data that helps it underwrite faster.

      That answer settles who lends. It doesn’t settle what the platform itself is responsible for, and that gap is where platforms run into trouble. 

      Two signs mean the arrangement has drifted from that standard structure, whatever the partnership deck calls it: 

      1. The loan agreement identifies the platform, rather than the NBFC, as the lender. 
      2. Repayments pass through the platform’s own bank account before reaching the NBFC.

      Key Takeaways

      • The licensed NBFC is the lender of record. It signs the loan agreement, disburses the funds, and carries the credit risk unless it has separately agreed to share part of that risk.
      • The platform’s role is that of a Lending Service Provider (LSP), an agent whose specific functions are set by its written contract with the NBFC, not by the LSP label alone.
      • RBI’s rules bar the platform’s own account from acting as a pass-through for disbursal or repayment. Both move directly between the NBFC and the seller’s bank account.
      • A platform only shares in a seller’s default loss if it has separately agreed to a Default Loss Guarantee (DLG), capped by RBI at 5% of the amount disbursed under that specific loan portfolio.
      • Not bearing default loss doesn’t mean the platform has no responsibilities. Under its LSP agreement, it may still handle onboarding, underwriting support, or collections outreach, work that continues whether or not a DLG is in place.
      • RBI holds the NBFC responsible for everything its LSP does on its behalf, including the platform’s conduct with sellers.

      Does Offering Sellers Credit Make Your Platform a Lender?

      No, not when the credit runs through a licensed NBFC partner. The loan stays on the NBFC’s books because the NBFC is the one that approves it, signs for it, and funds it from its own balance sheet. The platform just connects the seller to the NBFC and supports the process along the way, without extending the credit itself.

      On the flip side, a platform lending on its own account would need to register as an NBFC. Registration turns on how much of a company’s business is financial in nature, measured by the share of its total assets and gross income coming from financial activity, not by whether it uses its own funds. 

      Who is a Lending Service Provider Under RBI’s Rules?

      A Lending Service Provider, or LSP, is RBI’s term for an agent that carries out specific lending functions on behalf of an NBFC, under a written contract between the two. The Reserve Bank of India (Non-Banking Financial Companies – Credit Facilities) Directions, 2025 set this structure out in Chapter III.

      A platform becomes that agent by taking on one or more functions under its contract with the NBFC, such as bringing in customers, supporting underwriting, servicing a loan, or helping with recovery. Which functions it actually performs is set by that contract, not assumed from the LSP label. 

      What doesn’t move, regardless of the contract, is the lending decision itself: the NBFC underwrites and approves each loan, and a platform doesn’t take on credit risk simply by performing these functions well. Taking on part of that risk needs a separate written arrangement, covered further down.

      Who Signs the Loan Agreement, and Where Does the Money Move?

      Two things happen in this arrangement, and they’re worth keeping apart: who the seller’s loan agreement is with, and which bank accounts the money moves through.

      The seller signs the loan agreement with the NBFC. RBI’s rules require this document to name the actual lender, not the platform the seller uses day to day. 

      Money follows the same principle: the NBFC disburses funds directly into the seller’s bank account, and the seller repays the NBFC the same way. RBI’s rules bar the platform’s own account from acting as this kind of pass-through, or pool account, for either leg, with narrow exceptions such as co-lending. 

      None of this stops a platform building the experience inside its own interface. A seller can see an offer, work through the paperwork, and track repayments without leaving the platform’s app, under the platform’s own branding. What’s shown on screen is a design choice, separate from who’s lending and where the money moves; both stay directly between the seller and the NBFC.

      What Happens If a Seller Misses a Repayment?

      A missed payment, an account moving into collections, and a realized default loss are different points on the same timeline, and RBI treats them differently. 

      When a seller misses a payment, the NBFC’s collections process takes over first, sometimes run through the platform acting as its LSP under specific written instruction. If the seller still hasn’t caught up, RBI requires the NBFC to invoke any agreed Default Loss Guarantee within a maximum overdue period of 120 days, rather than waiting for a formal write-off. 

      Whichever point it’s resolved at, the underlying loss falls to the NBFC by default: it’s the lender of record, and it absorbs a seller’s default unless it has separately agreed to share part of that loss.

      A platform can take on part of that loss only through a separate, explicit Default Loss Guarantee, or DLG, under which it commits upfront, as the NBFC’s LSP, to compensate the NBFC for a defined share of losses on a specific loan portfolio. 

      Not every platform qualifies: RBI requires a DLG provider to be incorporated as a company, and the NBFC must complete its own eligibility and due-diligence checks before entering the arrangement. RBI also caps the cover itself: under Chapter III of the Directions, a DLG can’t exceed 5% of the amount disbursed under the specific portfolio it covers, tracked at any given point in time, not 5% of the platform’s total book.

      A platform without a DLG doesn’t inherit any of this by default. One that has signed a DLG takes on a defined, capped share of losses on the named portfolio, nothing broader.

      What Should You Confirm With a Lending Partner Before You Go Live?

      These four checks are worth running through with any NBFC partner before a seller credit offering goes live.

      1. Role and Paperwork

      Confirm the written contract required under RBI’s rules spells out which functions the platform performs (sourcing, underwriting support, servicing, recovery) and which stay with the NBFC. An agreement that doesn’t name these clearly leaves both parties guessing who’s accountable if RBI, or a seller, raises a complaint.

      2. Loan Agreement Ownership

      Check who’s named as the lender on the loan agreement itself, and how the platform’s own role is described elsewhere in the document. If either is unclear, or the platform is described in a way that could read as a lending party, that needs fixing before launch, not after a regulator or a seller raises it.

      3. Money Flow

      Ask which bank accounts disbursement and repayment move through, on both sides of the transaction. Funds routing through the platform’s own account, even briefly, is a pass-through arrangement RBI’s rules don’t permit for a standard NBFC-LSP structure, and it’s worth catching at the contract stage rather than after go-live.

      4. Default Handling

      Ask two separate questions: who follows up when a seller misses a payment, and whether the platform has agreed to a Default Loss Guarantee. If a DLG is part of the deal, get the exact loan portfolio it applies to and the percentage of that portfolio’s disbursed amount it covers, in writing, rather than a general sense of “coverage.”

      Where This Leaves Your Platform

      A platform offering seller credit through a licensed NBFC doesn’t need to become a lender to keep sellers funded and orders flowing. What it needs from a partner is paperwork that matches that structure: the NBFC’s name on the loan and its account handling the money, with default terms already agreed before a seller ever misses a payment.

      GLAAS builds that structure for digital platforms. In the arrangement this article describes, Gromor Finance, GLAAS’s own licensed NBFC, is the lender, underwriting off the platform’s own transaction data rather than relying on bureau scores alone. Other GLAAS arrangements may involve additional regulated lenders as co-lending partners. Platforms have gone live with a co-branded, no-code credit product in under two days, and seven in ten GLAAS borrowers come back for a second loan. 

      If you’re weighing this for your own platform, talk to GLAAS about what a seller credit line built on your transaction data would look like.

      Frequently Asked Questions

      1. What is a lending service provider (LSP) in India?

      An LSP is an agent that carries out specific digital lending functions, such as customer acquisition or loan servicing, on behalf of an NBFC, under a written contract. RBI’s Non-Banking Financial Companies – Credit Facilities Directions, 2025 govern this relationship.

      2. Is a platform considered the lender when it offers credit through a licensed NBFC partner?

      No. In this arrangement, the NBFC is the lender of record. It signs the loan agreement, disburses the funds, and carries the credit risk by default. The platform acts as the NBFC’s agent, not as a party to the loan.

      3. Does a platform need an RBI licence to work with a lending service provider structure?

      A platform does not need its own NBFC registration for the licensed-partner arrangement described here. A different lending model needs a separate assessment under RBI’s rules.

      4. What happens if a seller misses a repayment under this structure?

      The NBFC’s collections process runs first, sometimes through the platform acting as its LSP. If the loan isn’t recovered, the resulting loss stays with the NBFC by default, unless it has separately agreed to a Default Loss Guarantee (DLG) with the platform, capped by RBI at 5% of the amount disbursed under the specific loan portfolio the DLG covers.

      5. What does GLAAS do, and how is it regulated?

      GLAAS builds the technology that lets digital platforms embed seller credit inside their own apps, using each platform’s transaction data to underwrite. In this arrangement, Gromor Finance, GLAAS’s own licensed NBFC, is the lender; other GLAAS arrangements may involve additional regulated lenders as co-lending partners.

    3. Can a B2B Marketplace Offer Loans to Its Sellers Without an NBFC Licence?

      Can a B2B Marketplace Offer Loans to Its Sellers Without an NBFC Licence?

      Sellers facing a cash flow crunch between orders will find funding elsewhere, taking their next transaction to whichever rival platform or lender helps them first.

      Embedding working capital directly into your B2B marketplace prevents this vendor drift, keeping your users active and protecting your own transaction volume. 

      While these projects frequently feel overwhelming due to RBI compliance and the complexities of holding a licence, the regulatory reality is simple: your marketplace does not need to become a lender to offer credit.

      Key Takeaways

      • A marketplace needs an NBFC licence only if it expects lending to become its principal business, funded from its own balance sheet.
      • The route almost every platform takes instead is partnering with a licensed NBFC as a Lending Service Provider, a structure RBI recognises under its Digital Lending Directions, 2025.
      • The NBFC remains the lender of record. Loan money moves between the NBFC and the seller’s bank account, never through the platform’s account.
      • Credit risk sits with the NBFC unless the platform agrees to a default loss guarantee, which RBI caps at 5% of the loan portfolio.
      • What separates partners isn’t the licence they may hold. It’s whether they underwrite on your platform’s data and how fast they can move.

      Does a B2B Marketplace Need an NBFC Licence to Offer Credit?

      No, as long as it isn’t the one putting up the money.

      Section 45-IA of the RBI Act, 1934 requires a company to register before it can carry on the business of a non-banking financial institution. RBI’s test for whether you’ve crossed into that: do more than half your assets and more than half your income come from financial activity? If lending is running alongside your actual business rather than being your actual business, you’re on the right side of it.

      A platform extending small amounts of trade credit to a handful of sellers from its own funds is unlikely to be there. A platform funding a standing credit line for every seller on it, out of its own money, qualifies as “financial activity,” no matter what the internal team calls the product. And this isn’t a rule worth testing while you check for demand. Section 58B(4A) makes contravention punishable with a jail term of 1-5 years, plus a fine of ₹1 lakh to ₹5 lakh.

      Could a platform just get the licence itself? 

      It can, but it’s a separate business from the one you already run: fresh capital, a minimum ₹10 crore in net owned funds, paperwork with RBI, and ongoing compliance once you’re registered, not a one-time cost. Practitioners put the full timeline at 8 to 14 months before a rupee gets disbursed. 

      RBI’s Amendment Directions of 29 April 2026, effective 1 July 2026, make one exemption: NBFCs under ₹1,000 crore in assets that take no public funds and have no customer interface. A marketplace lending to its own sellers has a customer interface by definition, so this exemption doesn’t apply. There’s no small-scale version to start with and grow out of, registration is mandatory regardless of size. 

      What’s the Alternative, and How Does It Work?

      The alternative is to work with a company that already holds the licence and operate under it as its lending service provider.

      RBI’s Digital Lending Directions, 2025, effective 8 May 2025, set this structure out formally. A Lending Service Provider acts as agent of a Regulated Entity, which is a licensed bank or NBFC, and handles digital lending functions on its behalf: bringing in customers, supporting underwriting, servicing, monitoring, recovery. All of it under a written contract. The marketplace becomes the LSP. The NBFC stays the Regulated Entity, and it keeps everything that comes with holding a licence.

      Worth being clear on one point, because it’s where platforms sometimes assume more freedom than they have: the Regulated Entity stays answerable to RBI for what its LSP does in its name. Outsourcing a function doesn’t outsource the accountability for it.

      Who Actually Lends the Money, and Where Does It Go?

      NBFC Partner for Embedded Finance

      The NBFC is the lender on record, and the money moves directly between the NBFC and the seller’s bank account.

      Under the same 2025 Directions, disbursal has to move from the Regulated Entity to the borrower’s account and repayments have to travel back the same way, with narrow exceptions set out in the Directions. The platform’s own account can’t sit in the middle as a pass-through, and the loan agreement the seller signs is with the NBFC.

      For the platform, that’s less of a constraint than it sounds. Credit appears inside the seller’s existing experience, on the marketplace’s brand, while the money and the paperwork route around it.

      What Should You Check in an NBFC Partner for Embedded Finance? 

      Establishing the licence isn’t the deciding factor. What separates one partner from another is the operating detail underneath it. 

      • Underwriting depth: A partner scoring purely off bureau data is offering the same product a seller could get by walking into a bank. Underwriting that factors in GMV, repeat-customer behaviour, bank flow, and months active gets closer to how the seller’s business actually runs.
      • Integration speed: A co-branded, no-code product can go live in under 2 days, a fully native integration in around 2 weeks. Match the option to how urgently your sellers need credit, not to which one looks more polished in a demo.
      • Contract clarity: RBI’s 2025 Directions expect a written contract with defined roles and responsibilities, backed by proper due diligence between the Regulated Entity and its LSP.
      • Balance sheet capacity: A single NBFC’s balance sheet has limits of its own. A partner built to add co-lending relationships later means your seller credit doesn’t get capped by what one lender is willing to underwrite.

      This is where GLAAS comes in. It works for the platforms running underwriting on the platform’s own data rather than bureau data alone.

      GLAAS has disbursed more than ₹1,500 crore across 110,000+ loans to over 13,000 MSMEs (micro, small, and medium enterprises) through its platform partners, with 7 in 10 borrowers returning for a second loan. Numbers like that are one way to tell whether a partner has run this at scale, not just built the technology for it.

      What Your Marketplace Carries, and What It Doesn’t

      By default, the credit risk sits with the NBFC. When a seller falls behind, the NBFC’s own collections and recovery process takes over, and it stays off your marketplace’s books unless a default loss guarantee says otherwise.

      That default has a qualifier, and any partner who glides past it is selling rather than explaining. Chapter VI of the 2025 Directions permits a Regulated Entity to enter a default loss guarantee arrangement with its LSP, which means a platform can be asked to cover first loss on part of the book. RBI caps that at 5% of the underlying loan portfolio. The LSP offering it has to be incorporated under the Companies Act, 2013. Cover can only be held as cash, a lien-marked fixed deposit, or a bank guarantee. And it has to be invoked within 120 days of an account going overdue. 

      So the accurate version is: a marketplace can run seller credit with nothing on its own balance sheet, and many do. Whether it carries any first loss is a commercial term someone negotiates, not something the regulation settles for you. Ask about it in the first conversation rather than the fourth.

      Where This Leaves Your Platform

      A marketplace doesn’t need to become a lender. It needs to choose one. The harder question comes after that: does this partner underwrite on your platform’s own transaction data? Can it approve a seller fast enough to matter, before that seller goes looking elsewhere? 

      GLAAS is built for that seat. It runs the technology in the LSP layer, and Gromor Finance, its own NBFC, is the Regulated Entity that lends. Platforms go live with a credit product under their own brand, on a no-code embed, in under two days.

      If you’re working through this for your own platform, contact us now, and we’ll map what a seller credit line built on your transaction data would look like. No licence required on your end.

      Frequently Asked Questions

      1. Does a B2B marketplace need an NBFC licence to lend to its sellers?

      No, not if it partners with a licensed NBFC instead of lending from its own balance sheet. It operates as a Lending Service Provider, handling seller-facing functions like data sharing and onboarding, while the NBFC extends the credit and carries the risk.

      2. When would a marketplace need to register as an NBFC?

      Once lending becomes its own principal business: RBI’s test is whether more than half a company’s assets and income come from financial activity. Most platforms offering embedded credit through a partner never cross that line. 

      3. What is a Lending Service Provider (LSP) under RBI’s rules?

      An LSP is an agent that performs functions like customer acquisition, underwriting support, servicing, or recovery on behalf of a Regulated Entity, under a contract. RBI’s Digital Lending Directions, 2025 govern this relationship, and the Regulated Entity stays fully accountable for what its LSP does. 

      4. What does GLAAS do, and how is it regulated?

      GLAAS operates as a Lending Service Provider under RBI’s Digital Lending Directions, 2025. Its NBFC, Gromor Finance, is the Regulated Entity that carries the credit risk, using the marketplace’s own transaction data to underwrite rather than bureau scores alone. GLAAS has disbursed over ₹1,500 crore across 110,000+ loans to 13,000 MSMEs for platforms like Meesho and Razorpay, with seven in ten borrowers returning for a second loan.