Caveats and known limitations

This spec is opinionated, India-specific, and implementation-oriented, but it is not authoritative. The author is not a regulator, not a tax advisor, not a lawyer, and not a representative of any vendor mentioned. Decisions based on this content should be verified with the appropriate authorities and professionals.

The sections below detail where to be most careful.

Regulatory content

Always verify against the live RBI / SEBI / state-government text before acting. The regulator publishes updates continuously, and circular numbers, thresholds, percentages, and applicability change without much advance notice.

Specifically:

• RBI circular reference numbers quoted (e.g., DOR.CRE.REC.66/21.07.001/2022-23) are accurate to the best of the author’s knowledge as of the writing date. RBI sometimes amends or supersedes circulars; the most recent version on rbi.org.in is authoritative.
• Percentages, caps, and thresholds (e.g., DLG 5% cap, single-borrower exposure 25% of Tier-1, NOF ₹10 Cr) — these are current at writing time but may be revised.
• Master Direction effective dates sometimes have phased applicability; check the specific clause.
• State-specific rules (stamp duty, money-lending Acts, registration norms) change with state budgets and notifications.
• DPDP Rules are still maturing — text and operational specifics may evolve.

The compliance officer’s first job on the day they start is to build the live compliance calendar by going through every regulation that applies, with current text and current officer interpretation.

Vendor and pricing content

Vendor names, capabilities, and pricing ranges are based on public information at writing time. Pricing in particular is:

• Illustrative, not contracted. Volume tiers, custom packages, integration discounts, and competitive dynamics change pricing materially.
• Subject to commercial negotiation. Anything in the integrations / vendor sections is a starting point, not a quoted rate.
• Vendor capabilities change. Mergers and acquisitions (Karza → Perfios, etc.) reshape offerings. Verify current capability with the vendor.

Vendor URLs in this spec point to public homepages. Specific product names, feature lists, and APIs should be confirmed with vendor sales / docs at the time of integration.

Unit economics content

The financial scenarios (₹30 Cr, ₹100 Cr, ₹330 Cr) use conservative illustrative assumptions that the author believes to be defensible. Real-world numbers will differ based on:

• Actual borrower mix and credit quality (drives credit cost).
• Actual channel mix (drives acquisition cost and pricing).
• Actual cost of funds (depends on rating, scale, market cycle).
• Actual operating discipline (drives operating cost ratio).
• Specific co-lending economics negotiated.

The scenarios are decision-support templates, not forecasts. Run your own numbers with your team’s assumptions before any commitment.

Architecture and tech-stack content

The recommended stack (Java / Spring / Postgres / Camunda / Snowflake / etc.) is one well-reasoned choice for the described context. Alternative stacks are valid:

• Python / Django with Celery for workflow — common in fintech, especially with strong ML ambitions.
• Node.js / NestJS — modern, good async support.
• Go — for performance-critical services.
• PostgreSQL can be replaced with managed alternatives (Aurora, CockroachDB) per team preference.
• AWS can be replaced with Azure / GCP / OCI per team preference.

The pattern of the architecture (modular monolith, event-driven async, separate OLTP / OLAP, audited PII tokenisation) is more durable than the specific technology choice. Adapt to team strength.

Underwriting rules and grids

The rule library, scorecards, exposure caps, pricing grids, tenure grids, and risk-grade thresholds are illustrative starting points. Real policy must be:

• Approved by the credit head and board.
• Calibrated to actual cohort data once the platform has loans.
• Adjusted for the specific borrower segments the business pursues.
• Updated continuously based on portfolio performance.

The format of the rules (declarative, versioned, sandboxed) is the durable contribution. The specific numbers are starting points.

Co-lending API contracts

The API contract design in Section 7.3 is one valid design pattern. In practice:

• Every bank partner has their own technical standards for integration — SFTP file formats, API specifications, security models.
• Partner integration is bespoke per partner, with the platform’s standard adapter handling the common cases.
• Documenting per-partner deviations alongside the standard contract is essential.

What this spec is not

• Not legal advice. Compliance and legal must be reviewed by qualified professionals for the specific NBFC and product set.
• Not tax advice. GST, TDS, income tax implications discussed are general; engage tax counsel for specifics.
• Not investment advice. The business model, financial scenarios, and roadmap reflect the author’s view; investors should perform independent diligence.
• Not a guarantee of business success. Execution discipline is 90% of the outcome.
• Not a substitute for hiring senior practitioners. The CRO, Compliance Officer, Head of Credit, Head of Engineering, and Internal Auditor must be experienced people with specific Indian NBFC track record.
• Not vendor-endorsed. No vendor mentioned has sponsored, reviewed, or approved this content.

Items to double-check before acting

When you’re about to make a decision based on something here, the following deserve independent verification:

1. Any regulatory rule — verify the latest RBI / state text.
2. Any vendor commercial number — get current pricing in writing from the vendor.
3. Any tax / accounting treatment — confirm with chartered accountant or tax advisor.
4. Any technology version compatibility — Astro, Starlight, Spring Boot, PostgreSQL — verify supported versions at the time of build.
5. Any cost / time / headcount estimate — these are heavily context-dependent.
6. Any unit-economics number — re-derive with your assumptions.
7. Any co-lending term — partners have their own preferences; the standard pattern here is a starting point.

Reporting errors or improvements

If you find a factual error, a stale regulatory reference, a vendor name that’s changed, or a pattern that proved misleading in practice, raise it on the repo:

→ https://github.com/javajack/b2b-lending-india/issues

Corrections improve the spec for everyone.

Author

Rakesh Waghela — Tech and B2B Lending Solutions Architect. LinkedIn · X · Topmate.

The author offers consulting for teams building NBFC lending platforms in India. The spec stands independently; engaging the author is optional, not required to use this content.