GLAAS Blog

Blog

  • 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.

  • From Branches to Bytes: Why My Next Move Is Embedded Credit Infrastructure

    From Branches to Bytes: Why My Next Move Is Embedded Credit Infrastructure

    Only 14% of India’s MSMEs have access to formal credit. That leaves a staggering ₹25 lakh crore credit gap.

    I am not someone who likes to throw numbers around, but this one captures the scale of the problem I want to solve next.

    With a great team beside me, I spent 15 years building Fusion Finance, from the ground up to a public listing in 2022. When I stepped away in 2025, I began asking myself a fundamental question: How do we serve India’s MSMEs better, at scale, without simply replicating the traditional lending model?

    Where the Traditional Branch-Led Model Strains

    At Fusion, we built a network of nearly 1,500 branches, around 15,000 people and 4 million clients. That scale taught me a great deal about both the strengths and limitations of branch-led lending.

    1. Constraints of physical distribution

    Branch-led growth requires people, physical infrastructure and continuous investment. Ground-level attrition adds to the challenge, while reliance on Direct Selling Agents (DSAs) creates another vulnerability. DSAs work with multiple lenders and naturally direct business towards whoever offers the best incentive.

    The paradox? The person closest to your customer may not be working in your interest.

    2. The product-fit problem

    MSMEs are anything but standard. Their credit needs depend on business cycles, cash flows, inventory and growth opportunities. Yet traditional lending often relies on standardised products.

    As Finance Minister Nirmala Sitharaman observed at SIDBI’s 37th Foundation Day, “Standard products cannot serve non-standard businesses.”

    I saw this firsthand. When borrowers outgrew our products, they often moved elsewhere.

    We needed a fundamentally different approach.

    From “Apply” to “Embedded”

    I wanted my next venture to be relevant not just today, but 7-10 years from now. That meant challenging some of the very assumptions that had served me well in the past.

    I went back to the field, spoke to MSME owners and commissioned a study examining lending opportunities across asset classes, including gold loans and loans against property (LAP).

    Two developments stood out:

    • India’s digital public infrastructure: Aadhaar, UPI, GST networks and digitised financial records were making identity verification, transaction visibility and credit assessment increasingly digital.
    • The rise of business platforms: B2B marketplaces and software platforms were digitising orders, invoices, payments and other everyday business activities.

    Together, these developments pointed to a new possibility: credit could be offered at the point of economic activity, instead of waiting for the borrower to approach a lender.

    The study captured the opportunity clearly: “The next generation of lending growth will come from platforms, partnerships and personalisation at scale.”

    My conclusion was clear: the future of MSME lending lies not just in reaching borrowers, but in embedding credit into the platforms where they already do business.

    Credit Is Becoming a Flow Business

    The difference between traditional digital lending and embedded credit comes down to timing.

    • Apply: The borrower must stop what they are doing and approach a lender.
    • Embedded: Credit is available when the business need arises, within the platform the borrower already uses.

    An invoice is raised. An order comes in. Inventory needs replenishing. A cash-flow gap emerges.

    These are the moments when working capital matters most. Waiting for a borrower to visit a lender weeks later can mean missing the opportunity altogether.

    India’s TReDS ecosystem shows what digital credit infrastructure can do. Financing volumes grew from around ₹40,000 crore in FY22 to ₹3.47 lakh crore in FY26.

    Research on counter-credit practices among Mumbai’s neighbourhood grocery stores offers another insight: when credit was available at the point of purchase, customer retention rose from 74% to 92%.

    The principle is simple: credit delivered at the right moment can create value for both the borrower and the business serving them.

    What Does Truly Embedded Credit Look Like?

    The term embedded finance is used loosely. For me, the test is straightforward: Can an MSME access, manage and repay its loan within the application it already uses to run its business, without breaking the journey?

    Credit should fit naturally into the operating workflow. Where possible, repayments should align with business cash flows, and servicing should happen within the same digital environment.

    The objective is not simply a better digital interface. It is a fundamentally better way to distribute, underwrite and service credit.

    Why Infrastructure Matters

    In 2020, Andreessen Horowitz’s Angela Strange popularised the idea that in future, every company would become a fintech company.

    For MSMEs, I see a similar opportunity: every platform where businesses transact could become a channel for credit.

    But a marketplace or SaaS company should not have to build an entire lending operation or acquire a banking licence to serve its customers.

    It needs the right infrastructure underneath.

    That realisation brought me to GLAAS.

    I saw an opportunity to combine the reach of digital platforms with the capabilities of regulated lenders through a common technology and data infrastructure. GLAAS connects platforms, Lending Service Providers (LSPs), lenders and co-lenders, enabling credit to be distributed through existing business ecosystems.

    The ambition is to address two structural constraints I experienced at Fusion: the cost of distributing through people and branches, and the limits of standardised products.

    Technology at the infrastructure layer can help lower acquisition and servicing costs, improve underwriting through richer data, and enable more relevant credit products.

    The larger opportunity is to make credit a seamless part of how MSMEs operate, not another process they must navigate.

    My Next Move

    The next phase requires a different mindset: less dependence on physical distribution, greater use of data, deeper platform partnerships and technology designed around the borrower’s business.

    I am not moving away from lending. I am rethinking the architecture through which lending reaches customers.

    After 15 years of building physical lending infrastructure, I believe the next 15 years will be shaped by embedded credit infrastructure.

    That is why GLAAS.

  • Re-engineering For The World Where ‘Context’ Trumps ‘Identity’

    Re-engineering For The World Where ‘Context’ Trumps ‘Identity’

    This is my third article in the series of Category erosion and resultant implications. In the first, I introduced the concept of Category Erosion leading to a potential banking meltdown. In the second article, discussed potential consequences of such a category erosion. In this article, I will explain how this leads to inevitable re-engineering of the organisational pillars.

    In legacy banking, identity was destiny.

    If your identity was a “Retail Salaried Individual,” you were routed to a specific branch manager, given a standard CIBIL-based credit card, and served quickly.

    If your identity was a “Private Limited MSME,” you were sent to a commercial relationship manager, asked for 3 years of audited financials, and had to wait for days or weeks.

    But now, in a Context-First world, the labels don’t matter. What matters is what the business is doing at the exact moment it needs capital.

    An MSME ordering inventory on a B2B marketplace at 11:00 PM needs a ₹4 lakh checkout credit line at the time. If they have to go elsewhere, to prove their “Corporate Identity” to a bank, the transaction never happens, they order less or find alternate avenues.

    To build a financial institution or fintech suitable for a context-first, identity-second world, you have to fundamentally re-engineer five pillars: Systems, Processes, Org Structure, Partnerships, and Incentives.

    1. System Design: From Product Silos to Unified Ledger & API Mesh

    Traditional banking systems are vertical stacks (a core banking system for retail, a separate one for corporate). A context-first architecture must be horizontal and decoupled.

    You need a Three-Tier Architecture:

    • The Product & Compliance Engine (Backend): The regulated balance sheet and ledger.
    • The Orchestration Layer (Middle): Where the rules live. This layer takes incoming data from any context, translates it, and decides the risk profile in real-time.
    • The API Mesh (Frontend): Highly modular, plug-and-play APIs that can be embedded into an accounting software, an e-commerce platform, or a logistics app seamlessly.

    But, unified and decoupled systems only help if what runs through them changes too.

    2. Process Design: From Static Gatekeeping to Continuous Underwriting

    Legacy processes rely on static checkpoints (e.g., “Upload your ITR here”). Context-first processes rely on continuous, permissioned data streams.

    • The Real-Time Funnel: Instead of a loan application form, the process is an automated data handshake.
    • When a merchant applies for credit within a supply-chain app, they click “Allow Access.” The system pulls real-time transaction history via APIs (like account aggregators or GST networks), runs it through a programmatic underwriting engine, and assigns a dynamic limit in seconds.

    3. Org Structure: From Customer Segments to Capability Tribes or PODs

    If your bank’s organisational chart has a “Head of Retail” and a “Head of Corporate” who don’t speak to each other, you cannot execute a context-first strategy.

    • The Cross-Functional Shift: Organisations must restructure into Capability-Based Tribes. Instead of segmenting by the type of customer, teams should be organized around ecosystems:

    Once the above is in place, the question arises: who’s on the other side of that integration.

    4. Partnership Strategy: From Vendor/Referral to Embedded Co-Alliance

    In a context-first world, banks lose direct access to the customer interface. Therefore, your partner (the platform where the context happens) is no longer just a “sourcing vendor” or a Business Correspondent, they are an essential component of the infrastructure.

    • The Co-Alliance Model: Lenders must deeply embed themselves into the B2B/B2C platforms. The platform provides the context and rich data, while the financial institution provides the balance sheet and compliance framework.

    5. Incentive Design: Moving from Origination Volume to Portfolio Health

    This reminds me of Charlie Munger’s words: ‘Show me the incentive, and I will show you the outcome’. If the platform hosting the context is only incentivised on how many loans are disbursed, they will push for volumes. Now, how many of those are bad, that’s a risk to the lender.

    • Structuring the Alignment: RBI’s FLDG (First-Loss Default Guarantee) exists for this very reason.
    • The Shared Outcome: This completely aligns incentives. The platform is incentivised to maintain high-quality user engagement and clean data, while the funding lender is incentivised to provide lower interest rates and higher approval limits because their downside risk is protected by the context-owner’s skin in the game.

    In Summary: This is What the Shift Looks Like

    None of this needs a five-year transformation programme. Most of it is a series of decisions about who does what, and who gets paid for which outcome.

    The businesses stopped fitting the categories a while ago. The question is how long the categories hold out.

    If you’re building on either side of this, I’d be curious which pillar you think is hardest. My guess is the last one.

  • 4 Things that Change When the Credit Categories Collapse

    4 Things that Change When the Credit Categories Collapse

    I recently wrote how the line between retail and corporate credit is breaking down and how the phenomenon of category erosion is fundamentally rewriting the economics and operational playbook of financial institutions.

    After publishing it, I had a good discussion about what changes next.

    Well, 4 things in my opinion and here’s what can be done about them:

    1. The Collapse of Traditional Profit Pools

    Historically, banks were required to charge high fees and have wider margins on corporate/MSME lending because of the “bespoke manual processing”. As MSME lending automates, those operational margins are collapsing. Conversely, retail yield is under pressure, forcing institutions to find new revenue streams.

    2. Risk Assessment Shifts from “Static Assets” to “Live Data Flows”

    Traditional corporate lending relies on trailing financial statements (GST returns, balance sheets, ITRs). Retail relies on credit scores. Category erosion forces a shift toward Transaction-Based Underwriting. Because an MSME’s position changes faster than its filings do. Risk has to be read from current cash flow and platform sales, not from documents describing last year.

    3. Distribution is Fragmenting

    Traditional banks are losing direct ownership of the customer interface. When an MSME can get a working capital loan instantly inside their accounting software or their B2B sourcing marketplace, they have no reason to visit a bank’s portal. The bank is relegated to a utility backend.

    4. The Talent and Culture Mismatch

    Bank organisational charts are deeply siloed. Retail product managers don’t understand complex business cash-flow cycles, and corporate relationship managers don’t understand how to design frictionless, 2-click UI/UX. All of this slows down product innovation.

    What Can Financial Institutions and Fintechs Do?

    For starters, they must transition from a product-centric silo model to a layer-centric platform model. But that isn’t all:

    1. Adopt a “Lending-as-a-Service” (LaaS) Architecture

    Instead of forcing business users to come into your siloed retail or corporate channels, export your balance sheet into the ecosystems where businesses already live.

    The Play: Partner with an embedded credit provider, or build it in-house. By decoupling the manufacturing of credit (balance sheet, compliance) from the distribution (APIs embedded in B2B/SaaS platforms), you can deliver institutional-grade capital with retail-like seamlessness.

    2. Unify the Core Data Layer

    To serve the “individual acting like a corporation” or the “MSME wanting retail simplicity,” a bank must have a single, unified view of the customer. For instance, a proprietor’s business account and his personal account sit under the same PAN. Most banks still assess them as two unrelated customers, with separate risk profiles and separate limits.

    The Play: Break down internal data silos. The data to fix this exists. What’s missing is the decision to treat it as one relationship, which is a policy call, not a systems upgrade.

    3. Transition to Contextual & Programmatic Lending

    Stop selling static loan products (e.g., “3-year term loan”) and start offering dynamic credit lines that embed directly into the user’s business cycle.

    The Play: Develop rule-based, programmatic credit. For instance, a business’s credit limit should automatically scale up when their marketplace sales spike, and automatically sweep funds to repay the loan when invoices are settled, mimicking corporate treasury logic but executing with retail automation.

    4. Re-engineer Risk with Alternative Data Pipelines

    Since traditional credit history might be thin for emerging gig-workers or micro-merchants, risk frameworks must adapt to alternative data.

    The Play: Build underwriting engines that hook directly into e-commerce merchant dashboards, logistics data, payments aggregators, and cash-flow vectors. This allows you to assess a commercial borrower with the speed of a retail algorithm.

    In a nutshell… The old question was: ‘What documents can you show me?’

    The new one is: ‘What does your money actually do in a given month?’

  • The Great Banking Meltdown: The Erosion of “Retail” vs “Corporate”

    The Great Banking Meltdown: The Erosion of “Retail” vs “Corporate”

    For decades, the financial services playbook was written in stone:

    • Retail was high-volume and simple.
    • Corporate was low-volume, complex, and relationship-driven.

    That playbook isn’t just being revised, it’s being torn up. It is experiencing complete category erosion.

    The modern customer has broken the silos. Today, we are witnessing a double-sided convergence that traditional bank architectures are struggling to handle.

    1. The Consumerization of the MSME

    Business owners are no longer comparing their commercial banking experience to other banks. They are comparing it to how they use Amazon, Uber, or how fast money moves with UPI.

    According to Salesforce, 80% of customers now expect the experience a company provides to be as important as its products and services.

    An MSME applying for a working capital loan expects retail-like instant digital underwriting, clean APIs, and zero paperwork.

    2. The “Institutionalization” of the Retail User

    Conversely, the individual retail consumer is no longer just a simple salary earner. With the explosion of the gig economy and side hustles, the modern individual operates like a micro-corporation.

    They want corporate-style sophistication, dynamic cash flow management, automated tax routing, and contextual lending at the point of need.

    And here’s the contrast.

    Traditional banks that maintain rigid internal org structures (separate product teams, disconnected tech stacks, and distinct risk models for retail vs. commercial) are facing a massive bottleneck.

    On the other hand, fintechs and digital platforms don’t see “Retail” or “Corporate.” They see an economic unit with cash inflows and outflows that needs a seamless interface. Both of them now sit in the middle, and the middle is exactly where traditional banks drew the line.

    The Institutionalization of the Retail User

    This is where GLAAS Comes In

    Instead of forcing borrowers into rigid, legacy labels like “Corporate” or “Retail,” GLAAS operates on a unified, context-first philosophy.

    As a comprehensive, asset-light embedded credit infrastructure, GLAAS decouples lending from legacy banking drawers. It allows any digital ecosystem—whether a B2B supply chain, a gig-economy marketplace, or a consumer platform—to embed credit directly at the point of need.

    By centering the infrastructure around real-time cash flows, transaction velocity, and behavioral data rather than static legal entities, GLAAS transforms credit from a slow, paper-heavy approval process into an instantaneous feature. The focus shifts entirely from who the borrower is to what the economic context demands.

    The future of lending doesn’t belong to banks with the best, but siloed products; it belongs to the those that can put real working capital in front of a merchant without making them fill out dozens of forms.

  • 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.