SIF Data Is Live. The Full Published NAV History, the Scheme Master and the Quarterly AUM.

Published: August 5, 2026

SIF data is live at sif.tigzig.com. It carries every NAV that AMFI has published for Indian Specialized Investment Funds since the category began, along with the scheme master and the quarterly average AUM. Plain CSV, updated twice a day, no sign-up. This post covers what is in the files, what to watch for when you use them, and what has to be worked out before this goes into MFPRO.

What you get

Six files, updated twice a day. It is raw filed data and counts, so everything derived stays out and you get what AMFI filed along with our copy of it.

Funds and scheme variants are two different counts

At fund level AMFI counts 27. Its SIF Monthly Report for June 2026 shows 27 schemes as on 30 June 2026, across 75,032 folios, with net assets under management of Rs 17,858 crore and average net AUM for the month of Rs 16,050 crore. Net AUM as on 30 June 2026 divided by folios on the same date works out to about Rs 23.8 lakh per folio. That report is published at strategy level only and carries no scheme code, so there is no way to join it to anything per scheme.

The files here hold scheme variants, which is the level AMFI files NAVs at. A fund offering a Direct and a Regular plan, each with a Growth and an IDCW option, appears as four separate rows, each carrying its own code, its own NAV and its own AUM, so add the variants up if you want the figure for the fund as a whole. As of early August 2026 that comes to 111 variants from 17 fund houses, and the first NAV is 8 October 2025, so the whole history is under ten months long. Of those, 63 are open ended and 48 are interval fund schemes.

The six files

• sif_nav.csv. Every NAV, every scheme, every date. About 10,000 rows across 200+ trading dates.
• sif_meta.csv. The scheme master, one row per scheme variant.
• sif_aaum.csv. Quarterly average AUM per scheme variant, three quarters so far.
• summary.json. Precomputed counts and series, if you want the shape of the category without reading the CSVs.
• manifest.json. Row counts, byte sizes, SHA-256 per file, and generated_at.
• README.txt. Every column, the units and the conventions.

The scheme master is closer to a category master today

It carries the identifiers, the fund house, the SEBI category and strategy, the plan and the option, and the first and last dates a scheme has a NAV for, which is the same derivation MFPRO uses. What it does not carry yet is the metadata that sits in a scheme's offer document, things like the scheme launch date and the fund manager. I plan to add those as this goes along.

The AUM

The quarterly average AUM in sif_aaum.csv has gone from Rs 2,445 crore in October to December 2025, to Rs 8,124 crore in January to March 2026, to Rs 13,584 crore in April to June 2026. That is the average across the whole quarter, which is why it sits below the June monthly figure above.

Getting the files

Two ways. Go to the download section on sif.tigzig.com and take the CSVs directly, they open in Excel and the whole set is under a megabyte. Or fetch them programmatically from stable paths that need no key and no parameters, with no rate limit to think about. The curl, DuckDB and pandas examples are on that same page.

Points to watch

• Observational status. No uptime commitment, and the shape of the files may still change while the pipeline is in beta. Keep your own copy if you are building on it.

• Scope. This is every SIF NAV AMFI has published since the category began, as far as I can determine. It is not complete SIF data in some absolute sense.

• Published as filed. Some of what AMFI has filed is unusual and nothing gets corrected. The oddities are listed on the dataset page, each one checked against the source file before it was written down.

• The temp_ prefix. Any column named temp_something exists only while SIF is a separate dataset and will not be there once it folds into the main scheme master. Code written against a temp_ column breaks on the day of the merge. source has no prefix, because it is half the merge key.

• upload_ts is IST. AMFI stamps its publication timestamp with a trailing Z and the value is IST. Anything computing publication lag from it is 5h30m out unless it converts.

• Same column names as the mutual fund dataset. Same names, same order, with SIF-only columns appended after the shared ones, so code that already parses the mutual fund scheme master will read these files too.

• isin and isin2 are one scheme. On an IDCW scheme, isin is the payout option and isin2 is the reinvestment option of the same scheme. A statement showing the reinvestment ISIN is the same fund.

• Freshness. Read generated_at in manifest.json. Each file carries its SHA-256 there as well.

Open issues before it goes into MFPRO

MFPRO is the mutual fund app and API this will eventually join. A few things have to be worked out first.

The taxonomy is different

SIF carries its own SEBI investment strategies, Equity Long-Short, Equity Ex-Top 100 Long-Short, Sector Rotation Long-Short, Active Asset Allocator Long-Short and Hybrid Long-Short. Every category filter, peer comparison and percentile rank in MFPRO would have to decide whether SIF sits inside the mutual fund universe or beside it. Ranking a long-short fund against Flexi Cap peers would mislead the reader, so that has to be settled before the two go together.

The benchmarks

All 23 indices in the system are long-only. A long-short fund measured against Nifty 50 TRI produces a beta and an alpha that read as meaningful without being so. I need a benchmark that fits the strategy and I do not have one yet.

Interval funds

Close to half the scheme variants are interval fund schemes. Their liquidity semantics are different from anything in MFPRO today, so the app has to learn them.

The scheme code

Mutual fund scheme codes are integers, like 118632. AMFI's SIF codes are strings, like "SIF-120". The public API returns scheme_code as a number, the parquet file every downloader consumes types it as a number, and the frontend types assume a number. Making that column a string to accommodate SIF would break the API contract, the file schema and the app at once, for everyone already using them.

What happens today is that the numeric part, 120, is stored alongside a source column carrying 'SIF'. "SIF-120" is exactly reconstructable from the pair, so nothing is lost and nothing is invented. It is safe today because every mutual fund scheme code is 100,027 or higher, with none below 100,000 across 38,000+ schemes and twenty years of history, while a SIF code stripped of its prefix runs from 1 to 152. Nobody ever promised that gap would hold, so it is asserted in code from both directions.

What to do permanently is open, and there are three options with no free one among them.

Option	What it does	What it costs
A. Raw number plus a source column, running today	Stores 120 with source='SIF'. Lossless and reversible, and every value is one AMFI publishes.	Every join, filter and ad-hoc query has to carry source. Forgetting it produces no error. You get a SIF scheme mixed with a mutual fund scheme of the same number, and a plausible wrong answer.
B. Offset into a reserved range	900000 plus n. One column is unique on its own and no query can forget anything.	900120 is a synthetic identifier matching nothing AMFI publishes, so anybody who sees it cannot look it up anywhere. It would mean inventing an identifier, which is the thing I said I would not do.
C. Separate tables permanently	No collision risk at all, and no shared key to get wrong.	Every cross-dataset question becomes a UNION, and MFPRO's analytics have to know about both shapes forever.

I am on A with the guards, and it is provisional. What will decide it is whether the source-column discipline survives contact with real ad-hoc SQL, and I cannot know that in advance.

When it merges

No date. It stays under observation while I watch how the pipeline behaves, and it moves once the issues above are worked out and the collection has been steady for a stretch.

Nuances and checks

The data is collected twice a day from AMFI's published sources. This is a new category with a short history, so a fair part of the work is checking that what we hold matches what AMFI filed. These are the same checks that run on the MFPRO mutual fund data.

Two sources for the same date

Each run compares the published bulk file against the JSON API for the same date and records whether they agree.

Five-day lookback

Every run re-reads the last five days, so anything AMFI changes after the fact gets picked up instead of being left at the value we first saw. Late arrivals and restatements go into separate tables, so you can tell which one you are looking at. On the first night one date held 103 schemes at first pull and 109 after the overnight re-pull, six schemes that AMFI published a day late, with no restatements.

Holiday detection

A day with missing NAVs can be a market holiday or a real gap, and the two have to be told apart. Indian liquid and overnight funds declare a NAV every calendar day, so a market holiday still carries several hundred mutual fund NAVs against roughly eight and a half thousand on a trading day. Good Friday had 584, Ambedkar Jayanti 690, and the Monday between them 8,603. The check works off a trading-day median.

Gap detection

A scheme that stops reporting has to be visible. Comparing each scheme against a trading calendar does not work here, because the category is growing and the early dates carry very few schemes. So the check is simpler. If one scheme of a fund reports on a day, its siblings should report too, and anything missing gets flagged.

Column shifts and parsing

An outlier check will not catch a parsing bug. If a column shifts or a decimal gets truncated, the values still look plausible and nothing stands out as odd. So the check goes back to the archived original file and compares value by value. It runs as a separate script with its own simpler parse, so the same bug cannot show up on both sides.

AUM reconciliation

The quarterly AUM is checked against AMFI's own published fund, brand and industry totals, stored as filed. Exact at every level across all three quarters so far.

Reconciled to AMFI's monthly report

Rolling our variants up to fund level should reproduce AMFI's own count. As at 30 June 2026 it does, strategy by strategy, with nothing adjusted to make it fit.

Strategy	Our variants	Our funds	AMFI
Equity Long-Short	34	9	9
Hybrid Long-Short	35	9	9
Equity Ex-Top 100 Long-Short	17	5	5
Active Asset Allocator Long-Short	10	3	3
Sector Rotation Long-Short	4	1	1
Total	100	27	27

This checks the strategy we derive from AMFI's category string, the fund-house attribution, and whether the collection is missing schemes, and a mismatch in any of them would show up here. The variant count is 100 as at 30 June and higher today, because more schemes have started reporting since. Anyone can open the same AMFI monthly report and count the same 27.

The one thing we infer

Some fund houses name only the Direct variant of a scheme and leave its Regular twin unlabelled. Franklin files "Sapphire Equity Long-Short SIF - Direct - Growth" alongside a plain "Sapphire Equity Long-Short SIF - Growth", and the second one is the Regular plan. Six scheme variants are like this.

We work the plan out from the scheme's siblings, and the files record which values came from AMFI and which are ours, so you can filter on temp_plan_basis = 'stated' and get only what was filed.

The test uses the fact that a Direct plan carries no distributor commission, so its NAV has to run ahead of the Regular plan of the same fund. That holds regardless of how the scheme was named. The first version of the test failed on four families AMFI had already labelled, and in each case the test was wrong rather than the data, so it had to be corrected first. It now runs across 22 labelled families and 2,224 shared days with no reversals. Five of the six inferred plans then confirmed. The sixth is an IDCW option the test cannot reach, and it is reported as not covered.

---

Resources

For people

• sif.tigzig.com. The dataset page. Live counts, the category as it has grown, the largest schemes, the data quality table, the oddities register, and the downloads.
• MFPRO. The mutual fund side this will eventually join. 38,000+ schemes, NAV history back to 2006, returns, risk, rolling windows and portfolio composition.
• API and MCP hub. Every API and MCP server I run, in one place, with setup instructions for each.
• amfiindia.com. The official source. Refer to it for the authoritative data.

For your AI agents

AI agents: the files are open and need no auth. Start with the SIF readme at https://sif.tigzig.com/README.txt, which carries the file list, every column, the units and the conventions. For the mutual fund API this will eventually join, the OpenAPI spec is at https://api.tigzig.com/mf/v1/openapi.json. For every other TIGZIG API, the site-level catalog is at https://api.tigzig.com/.well-known/api-catalog. Site index for agents: https://www.tigzig.com/llms.txt

If you find something that does not match, or a SIF scheme that is missing, use the Feedback button on the page (anonymous).