India's MCA feed still carries the Y2K date bug

Two-digit incorporation years still turn up in parts of the MCA bulk feeds. Last month I hit a CIN record where an upstream parser treated 01-01-00 as 1900 during a sanctions-linked subsidiary trace. Small bug. Big consequences. One bad date can push a company earlier than the existence of its own parent when you are rebuilding ownership timelines across four jurisdictions.

India’s Ministry of Corporate Affairs exposes company data through MCA services and downstream data.gov.in datasets, though the structure swings wildly between sources. Some records arrive properly typed. Others still carry formatting decisions inherited from filing systems built long before anybody expected API consumers to parse them automatically. You can pull useful registry intelligence out of the data, though it helps to treat filings as statutory records rather than reference data cleaned for analysts.

OpenRegistry does not currently serve the IN jurisdiction. The live matrix marks India as inactive, so there is no MCP passthrough for MCA queries right now. Registry behaviour shifts often around filing access, session handling, or CAPTCHA enforcement. Better to mark coverage offline than pretend an old integration still works.

The structure still matters because Indian entities show up constantly in cross-border reporting chains. Offshore structures involving Mauritius, Cayman, Singapore, or Dubai often terminate in an Indian operating company. During one ownership reconstruction tied to procurement records, I ended up matching DIN numbers against director names from leaked spreadsheets because the register itself handled transliteration inconsistently across filings.

The identifiers are fairly readable once you know the layout. The Corporate Identity Number, or CIN, encodes listing status, industry classification, state registration, incorporation year, plus registrar office. Director records use DIN identifiers. LLP entities carry LLPIN values instead.

When MCA responses are available programmatically, the payloads usually expose fields like:

• cin
• company_name
• company_status
• date_of_incorporation
• registered_office_address
• authorised_capital
• paid_up_capital
• director_din
• director_name
• filing_date

Normalisation causes most of the pain. Addresses arrive as free-text blocks with inconsistent state abbreviations. Historical filings contain OCR artefacts. Director names drift between annual returns through spacing changes or shifting initials. Exact string matching falls apart quickly if you are tracing politically exposed persons or procurement beneficiaries.

Public access and paid retrieval are split awkwardly as well. Basic company profiles are accessible through MCA-facing services. Full filings follow another route entirely. Annual returns, balance sheets, charge documents, incorporation PDFs: many sit behind fee workflows or session-bound requests that break automated collection.

India also handles beneficial ownership differently from some European registers that briefly exposed broader public UBO access before the CJEU C-601/20 ruling shifted the position across the EU. Significant beneficial ownership obligations exist under Indian company law, though public machine-readable access remains narrow.

The filings still matter because they create timelines that can be checked later. Director appointments, registered office changes, strike-off notices, charge creation dates: each becomes an anchor point during reporting work. Newsrooms working from leaked datasets usually care less about whether a register feels modern and more about whether another team can reproduce the same trail six months later.

If India coverage returns inside OpenRegistry, the MCP flow would probably begin with a company search:

{
  "tool": "search_companies",
  "arguments": {
    "jurisdiction": "IN",
    "query": "Adani Enterprises"
  }
}

After that, a profile pull against the CIN returned from search:

{
  "tool": "get_company_profile",
  "arguments": {
    "jurisdiction": "IN",
    "company_number": "L51100GJ1988PLC010856"
  }
}

For reporting work, the next step is usually filing enumeration rather than stopping at the profile layer:

{
  "tool": "list_filings",
  "arguments": {
    "jurisdiction": "IN",
    "company_number": "L51100GJ1988PLC010856"
  }
}

Chronology matters here. Charge satisfaction records can expose lender relationships that never appear in company websites or investor material. Director resignations often line up with enforcement actions or media scrutiny. Some entities look dormant until you inspect annual returns directly and notice the same address reused repeatedly across related companies.

Language handling creates another awkward corner case. MCA records are mostly English-language, though supporting documents can include transliterated names from Hindi or regional languages. Matching against court filings, customs data, or leaked procurement spreadsheets gets fuzzy fast. I have seen the same surname rendered three different ways across registry extracts tied back to a single DIN.

Compared with the legacy paid databases, direct registry access gives you provenance. You can cite the statutory filing itself rather than relying on a reshaped ownership graph. Aggregators often flatten Indian entities into simplified structures while discarding registrar metadata that later matters during fact-checking or libel review.

India also sits in an uncomfortable middle ground for compliance engineering. The register is broad enough to support KYB work, though not clean enough to trust without review. Edge cases keep surfacing: struck-off restorations, duplicated director names, recycled addresses, historical filing corrections that overwrite earlier assumptions.

OpenRegistry currently serves 30 active jurisdictions including GB, KY, RU, HK, and IT. India remains inactive in the live matrix today. When IN returns, the MCP endpoint will expose upstream MCA fields directly instead of reinterpreting them. Current jurisdiction availability is listed at openregistry.sophymarine.com/mcp

Comments

[Mads Hansen]

The dangerous step is converting 01-01-00 into one confident date. For registry and KYB pipelines I would preserve the raw field, emit candidate interpretations such as 1900 and 2000, record the parser rule/version, and let chronology constraints reduce the ambiguity. A company cannot predate its statutory regime, parent, or related filing trail, but that inference should remain provenance, not overwrite the source. If this is exposed through MCP, returning the normalized date without the raw value and confidence metadata invites an agent to turn a parser guess into a factual claim.