India needs a CIBIL for litigation because its 28 crore+ public court records, and growing, sit scattered across 25 High Court portals and 700 plus district portals, leaving lenders, insurers and due diligence teams unable to check a borrower’s pending cases. A standardised, aggregated API layer would fix that, exactly as CIBIL fixed credit history.
In 2001, an Indian bank deciding whether to lend to a small business had no easy way to know if the borrower had defaulted on a loan at another bank six months earlier. The information existed. It was scattered across the credit files of three hundred plus banks and NBFCs, locked behind paper records, opening hours and the cooperation of the bank that held the file. The transaction cost of asking was so high that almost no one asked. Lending happened on the strength of relationships and gut.
In 2026, the same Indian bank deciding whether to lend to the same small business has no easy way to know if the borrower is facing a Section 138 cheque bounce prosecution that has been pending for nine years in a Pune sessions court, is a named director in a company being wound up at the Mumbai NCLT, or has been sued for partition of family property in a Patna civil court. The information exists. It is scattered across 25 High Court portals, seven hundred plus district complex portals and a long tail of tribunal sites. The transaction cost of asking is so high that almost no one asks. Lending still happens on the strength of relationships and gut.
The first problem was solved by the credit bureau. The second problem is waiting for the same solution. This post is about why India needs a CIBIL for litigation, what such a system would look like, and why the architecture for it is already in place.
What CIBIL actually did
It is worth being precise about what the credit bureau did and did not do.
CIBIL did not create new data. The data already existed at every bank and NBFC. CIBIL did not give itself authority over the data. The lenders retained ownership and reporting responsibility. CIBIL did not invent the underwriting decision. The banks still made the call.
What CIBIL did was three things. It standardised the reporting format so the same field meant the same thing across every reporting institution. It aggregated the reports into a single queryable record per borrower. And it built the API and price model that let every Indian lender check that record in seconds, for a few rupees, as a checkpoint in their underwriting flow.
The transaction cost of asking dropped by three orders of magnitude. The information stayed where it was. The standardisation, aggregation and API access changed the entire shape of Indian lending.
Twenty years later, no Indian lender underwrites without pulling a CIBIL report. TransUnion took majority control of TransUnion CIBIL around 2017, raising its stake over the following years; the 2017 stake sales implied a CIBIL valuation of roughly Rs 3,800 crore (about 592 million dollars). The product had nothing fancy in it. It was a standardised aggregator with an API. The value came from being the standardised aggregator that everyone could trust.
Why court data is the next CIBIL
The structural shape of the problem is identical.
The data exists. More than 28 crore court records and growing across the country, including every party named in every matter, every advocate of record, every order passed, every section invoked, every relief granted. The records are public. The portals exist.
The data is scattered. 25 High Court portals, spread across 41 bench locations, on as many schemas. Seven hundred plus district complex portals with regional variations. The Supreme Court portal. Tribunal portals. There is no single queryable surface today, despite the records being public.
The transaction cost of asking is high. A bank that wants to check whether a borrower has pending litigation has to either run paralegals across multiple portals or skip the check. Most lenders skip the check. The information advantage stays where it was twenty years ago.
The need is real. We covered the use cases in From Paralegals to APIs. Banks need it for loan underwriting and portfolio monitoring. Insurers need it for fraud detection. BGV firms need it for pre employment checks. Corporate teams need it for counterparty due diligence. Regulators need it for ongoing oversight. Every one of those buyers is structurally similar to a 2001 era lender who could not see the credit history they needed.
The fix is the same fix. Standardise the reporting format. Aggregate the records into a single queryable layer. Build the API and price model that lets every Indian buyer ask the question for a few rupees in milliseconds.
That is what a CIBIL for litigation looks like.
What it would actually do
The product class is concrete. A lender, insurer or BGV vendor sends a structured query through the API. The query identifies the entity, a person, a company, a director, a director’s connected companies. The response returns a clean, standardised record. Active matters. Disposed matters. Counter party history. Litigation density. Risk flags by category. Trend over time. Pending hearings. Recent orders. All linked, all dated, all sourced.
The lender uses the response inside their underwriting flow. The insurer uses it for fraud screening. The BGV vendor uses it inside their report. None of them have to learn the structure of any court portal. None of them have to maintain a scraper. None of them have to translate Hindi orders or resolve advocate name variations.
The information advantage that was previously available only to firms with paralegal teams becomes available to every regulated buyer in the country. The cost per check drops from hundreds of rupees to single rupees. The latency drops from days to seconds.
This is not a hypothetical product class. The first wave of enterprise demand for this exact API surface is already underway. We have written about the workflow shape for General Counsel in Litigation Portfolio Monitoring for General Counsel: A Claude + eCourtsIndia MCP Playbook. The B2C variant for litigants and household due diligence is the next leg.
How it differs from a credit bureau
Three differences worth being clear about.
The data is public, not lender contributed. CIBIL aggregates reports that banks file. The litigation aggregator pulls from public court portals that anyone could in theory query. The legal framework is different. The economic structure is similar.
The signal is broader. A credit report tells you about repayment behaviour on regulated credit. A litigation report tells you about dispute behaviour across every category of life. Commercial fraud, criminal allegations, family separations, regulatory actions, property fights, contract enforcement. The breadth of signal is structurally larger.
The data is harder to structure. Credit data comes in pre standardised reports from lenders trained to file them. Litigation data comes as scanned PDFs in nine languages from 25 High Court portals on as many schemas. The structuring work is the entire moat, and it is the reason the litigation aggregator did not exist for twenty years after the credit bureau did. We made the moat argument in The Data Moat in the Age of Commodity LLMs.
Why the moment is now
The same three shifts we have written about before are why this is feasible today and was not feasible ten years ago.
The eCourts Project completed digitisation across the district tier under Phase II, now continued under the Phase III programme (a Rs 7,210 crore outlay running 2023 to 2027). The underlying records are now digital across more than 29,000 courts and tribunals (29,358 establishments). The portals are imperfect at the surface but the data exists in CIS underneath.
Modern AI and OCR made vernacular legal text tractable. The unit economics of structuring orders in Tamil or Marathi at scale flipped from impossible to routine.
MCP and API standards normalised how enterprise systems consume third party data. Banks, insurers, BGV vendors and corporate teams already speak the format. The court data provider just has to meet them where they are.
These three shifts make the litigation aggregator buildable at a price point that supports the CIBIL business model. Subscription tiers for high volume buyers. Per query pricing for low volume buyers. Bulk batch pricing for due diligence. The same shape that powered credit bureau adoption powers this category.
The early adopter advantage
The lenders who plugged into CIBIL in the first three years of the bureau, between 2001 and 2004, had a structural underwriting advantage on the lenders who waited until 2008. The early adopters built five years of cleaner loan books, fewer non performing assets, and more accurate risk pricing. The late adopters spent the next decade explaining to their boards why their books contained exposures everyone else had been able to see for years.
Litigation data is the next instance of that pattern. The lenders who plug into the structured court data layer in 2026 and 2027 get a similar multi year information advantage. The ones who wait until 2030 will be the ones explaining why a borrower their book funded was carrying a six year pending criminal complaint or a sister company in insolvency that the lender did not check for.
The window to be an early adopter closes when enough peers have integrated that not having it becomes a regulatory or audit liability. That window, in our read, is about eighteen months.
What this means for eCourtsIndia
India already built CIBIL for credit risk and it changed lending. The same shape is overdue for legal and regulatory risk. We are building the substrate that lets every lender, insurer, BGV vendor and corporate team ask the litigation question for a few rupees in milliseconds. The data is public. The structuring is ours. The enterprise demand exists. The window to be early on this is roughly eighteen months.
TL;DR
- CIBIL solved the credit history problem by standardising, aggregating and API exposing existing lender data. It did not create new data, it made the existing data usable.
- India needs the same architecture for litigation. The data is public, scattered across 25 High Court portals, and structurally rich enough to power lender, insurer, BGV and corporate due diligence decisions.
- The structuring work is the entire moat. Vernacular OCR, entity resolution, cross court schema, daily refresh, deep history.
- eCourts Phase II digitisation, modern AI, and MCP plus API standards now make the product class feasible at CIBIL economics.
- Early adopters get a multi year information advantage on underwriting. Late adopters explain the gap to their boards. The window is roughly eighteen months.
Sources
- TransUnion CIBIL valuation reference, 2017 stake sales
- Reserve Bank of India guidance on credit information bureaus
- Press Information Bureau release on eCourts Phase III outlay
- Ministry of Law and Justice pendency data
- All India court coverage figures verified against the eCourtsIndia structured data index
Read next: From Paralegals to APIs and The Data Moat in the Age of Commodity LLMs.
Frequently Asked Questions
What is a CIBIL for litigation?
A CIBIL for litigation is a standardised, aggregated API layer over India’s public court records that lets lenders, insurers and background verification vendors check an entity’s litigation history in seconds for a few rupees, exactly as CIBIL aggregates credit data. The data is already public; the structuring is the value. Developers can plug into it through the eCourtsIndia API.
How much court data exists in India?
India holds 28 crore+ court records and growing covering every party, advocate, order, section and relief, spread across 25 High Court portals, 700 plus district complex portals, the Supreme Court and tribunals, sitting on top of 29,000+ digitised courts (29,358 establishments) after eCourts Phase II. You can query this consolidated record through case search.
Who would actually use a litigation data API?
Banks use it for loan underwriting and portfolio monitoring, insurers for fraud detection, background verification firms for pre employment checks, corporate teams for counterparty due diligence and regulators for oversight. Each buyer resembles a 2001 era lender who could not see the history they needed. We mapped these use cases in From Paralegals to APIs.
Why is court data harder to structure than credit data?
Credit data arrives as pre standardised reports from lenders trained to file them. Litigation data comes as scanned PDFs in nine languages across 25 High Court portals on as many schemas, demanding vernacular OCR, entity resolution and cross court schema mapping. That structuring work is the entire moat, which is why the aggregator did not exist for twenty years. Read The Data Moat in the Age of Commodity LLMs.
How long is the early adopter window?
In our read the window is roughly eighteen months. Lenders who integrated CIBIL between 2001 and 2004 built cleaner loan books and fewer non performing assets than those who waited until 2008, and the same advantage now applies to structured court data. Litigants and advocates can start checking case histories through litigant search.