Part 1 — Indian Financial Compliance: What It Is, How It Works, and Why It Needs a Platform
India's financial system touches every person and every business. Six regulators. Hundreds of documents. Constant updates. This part explains the ecosystem — before any technology is introduced.
Background — Why This Project Exists
India's fintech sector is one of the fastest-growing in the world
Over 10,000 registered fintech companies. UPI processes 14 billion transactions a month. SEBI, RBI, and IRDAI are each independently issuing new guidance, amending existing rules, and overhauling entire regulatory frameworks — simultaneously. The pace of regulatory change is not slowing down. It is accelerating.
The compliance cost is becoming a barrier to building
A fintech startup launching a combined lending and investment product must simultaneously comply with RBI's NBFC rules, SEBI's Investment Adviser regulations, IRDAI guidelines, three GST statutes, the IT Act, PMLA, and the Companies Act. Maintaining accuracy across all six regulators requires a full-time legal and compliance team — before a single line of product code is written.
AI is being deployed — but failing on the hardest questions
The natural response has been to point AI at the regulatory documents. Build a chatbot. Embed the PDFs. The system gives confident, well-written answers — and gets the hard questions wrong in ways that are invisible until an audit, a penalty, or a client complaint. The failure is not in the model. The failure is in the document structure feeding the model.
The Problem Statement
India's regulatory document corpus is not a library you can search. It is a layered, cross-referencing, constantly-superseding system of legal authority — and a generic AI search index has no way to understand any of that.
200+
document types
across 6 regulators, each with different legal authority
6
independent regulators
CBDT · CBIC · RBI · SEBI · IRDAI · MCA — each with its own document hierarchy
4
user personas
each needing opposite things from the same corpus — simultaneously
Meet Ananya — The Person the System Serves
Understanding the user before the technology
User Profile
Ananya — 27 years old, Mumbai
She downloads a fintech app. She does KYC. She invests ₹5,000/month in an SIP. She borrows ₹30,000 for a phone. She buys term insurance. She asks a tax question at the end of the financial year. She is not a lawyer. She is not a compliance officer. She is the end-user — and every product decision, every compliance obligation, every regulatory requirement in this system ultimately exists to serve her correctly.
She downloads a fintech app and does KYC
KYC is mandated by PMLA 2002, RBI KYC Master Direction, and FIU-IND. Three regulators, one onboarding step. If the product team does not know all three sets of requirements, the app fails compliance before its first user.
She invests ₹5,000/month in a SIP
SEBI regulates mutual fund distribution. AMFI governs distributor registration. The Investment Adviser regime (SEBI IA Regulations 2013, amended 2020) may apply depending on whether advice is given. The fintech must know the difference.
She borrows ₹30,000 for a phone
RBI's Digital Lending Guidelines (Master Direction 2022) govern the full stack: LSP agreements, Loan Service Provider obligations, KFS disclosure, cooling-off period, grievance redressal. 23 prior circulars are superseded by one Master Direction — which one is current?
She buys term insurance
IRDAI product approval, premium collection regulations, policy servicing rules. The fintech acts as a Corporate Agent — separate IRDAI registration and conduct rules apply on top of the insurance product rules.
She asks a tax question
"What TDS applies on my SIP redemption?" The answer depends on the type of fund (equity vs debt), holding period, applicable Finance Act amendments for the current FY, and CBDT circulars. A system that retrieves a superseded circular or a Budget Speech press release answers incorrectly — and Ananya is none the wiser.
Why one company cannot do this manually: At each step, a different regulator applies. No single expert knows all six well enough to maintain accuracy at scale. The compliance cost of manual tracking across all six regulators is prohibitive. This is the business case for a Knowledge Engineering layer.
Four People Who Need This System — and Need Different Things From It
The same document corpus, four completely different query needs
This is one of the central design challenges: the same 200+ documents serve four different professional users who need opposite things from the same corpus. A system built for one will fail the others.
Chartered Accountant (CA)
Needs: Enacted law only. Current financial year. Section-level precision. Auditable citations.
Must not get: Proposed amendments, superseded circulars, FAQs with zero legal authority.
Example query
"What is the TDS rate on interest paid to an NRI on an NCD for FY 2025-26?" — must return IT Act §195, not a Budget Speech or CBDT FAQ.
Compliance Officer
Needs: All active obligations across all 6 regulators for a given product type. Structured, attributed, exportable.
Must not get: Silent gaps from missed regulators, mixed proposed + enacted results.
Example query
"Show all active obligations for a digital lending product launch." Must span RBI, CBDT, CBIC, PMLA, Companies Act — none silently missing.
Dev Team
Needs: Machine-readable obligation objects. Structured JSON. Trigger conditions. Version-locked.
Must not get: A PDF to parse, prose to interpret, obligations discovered only in a compliance audit.
Example query
GET /rules?domain=RBI&product=digital-lending returns structured JSON rows, not paragraphs. When RBI amends a circular, the API reflects the change — no manual PDF reading.
Policy Team
Needs: Proposed changes only. Forward-looking. Impact analysis. Clearly separated from live law.
Must not get: Proposed documents mixed into compliance queries. GST Council recommendation treated as enacted law.
Example query
"What regulatory changes are proposed for NBFC digital lending in the next 12 months?" — must surface T4 documents ONLY, with explicit proposed/not-yet-operative labels.
What RegIntel Builds — The Solution at a Glance
Four layers — each part of this series covers one in depth
A structured document registry
Every regulatory document classified by authority tier, issuing body, legal status, effective dates, and supersession relationships. Not a flat index — a structured knowledge base that understands its own hierarchy.
Covered in Part 2An extraction pipeline
An AI pipeline that reads regulatory prose and pulls out structured obligations — who must do what, under what conditions, by when — stored as structured data, not text passages.
Covered in Part 3A persona-aware retrieval layer
A GraphRAG architecture that routes queries differently depending on who is asking — the CA gets enacted law only, the Policy team gets proposed changes, the Dev team gets structured JSON rules.
Covered in Parts 3 & 4A provenance display layer
Every answer traces back to its source — which document, which section, which version, on which date it was operative. Every answer is auditable. Nothing is a black box.
Covered in Part 4Want to explore what you can build or achieve?
Whether it is a product idea, a compliance challenge, or an engineering question — let's talk through it.