Daily ETF Holdings Download: 2026 Guide

A daily ETF holdings download is a file, usually CSV, listing every position a fund held as of a stated date, with weights, share counts and security identifiers. That definition is simple. What is not simple is that three quite different products are sold under the same phrase, and only one of them survives contact with a reconciliation process that runs before the market opens.

This guide covers the mechanics that decide usability: when files are published relative to the fund's as-of date, which columns make the file joinable to anything else you hold, what a bulk CSV over FTP does that an API does not, and how far the archive has to reach before a backtest stops being quietly survivorship-biased. The vendor comparison comes last, because the file format determines the vendor choice, not the other way round.

What is a daily ETF holdings download?

A daily ETF holdings download is a machine-readable file, refreshed each business day, that lists every constituent of a fund as of a stated date, including identifiers, share counts, market values and portfolio weights. The word "download" hides three distinct products.

The first is a screener view: a web page that renders holdings for one fund, sometimes with a CSV export button. The second is a per-fund file, typically the issuer's own disclosure, one file per ticker per day. The third is a bulk feed: one delivery covering thousands of funds and indexes at a fixed time, designed to be picked up by a scheduled job rather than a human.

These are not tiers of the same thing. A screener answers a research question in a browser. A bulk feed populates a database. If you need to reconcile 400 fund positions before the open, exporting 400 CSVs by hand is not a slower version of the right answer, it is a different workflow that will fail on the day someone is on holiday.

The shape of the file, not the marketing label, determines what you can do with it downstream. A page that calls itself an ETF holdings database and delivers one fund at a time through a browser session is accurate in its wording and useless for batch work.

When are holdings files actually published, and what date do they reflect?

Almost every daily holdings file you receive reflects the prior close, not the current session. The fund strikes its portfolio at the end of the trading day, the issuer publishes disclosure overnight or the following morning, and the data vendor normalises and republishes on its own schedule. The as-of date inside the file is the fact that matters; the time you received it is a separate fact.

This is where most integration bugs start. A file that arrives at noon Eastern on Tuesday usually carries Monday's as-of date, and a team that stamps its own ingestion timestamp onto the records will silently shift the entire history by one day.

Intraday screener pages and downloadable files can also disagree, and legitimately so. Some web views blend the last disclosed portfolio with intraday price movement to show a live-ish weight, while the file preserves the disclosed close. Two different numbers for the same fund at the same moment is not necessarily an error in either, but it is a reason never to reconcile a file against a screenshot.

Fixed publication times beat fast publication times

A portfolio team reconciling before the open needs to know that the file will be there at a specific time, every time. Speed matters less than determinism, because a job that runs at 5:30am can wait for a file that lands at 6pm the previous evening, but it cannot wait for a file that lands "usually by mid-morning".

AmericanETP publishes on a twice-daily cadence: a primary update at 6pm EST and a secondary run around noon EST. The evening run is the one an overnight batch should key off, since it carries the completed prior-session portfolio. The midday run exists to pick up late or corrected issuer disclosure, which is why a reconciliation process that only ever reads the evening file should still re-read the midday file before treating a discrepancy as real.

Worth building into your scheduler from day one: log the arrival time of every file against the stated schedule, from the very first week. A vendor's reliability is an empirical question, and you can only answer it if you kept the timestamps.

What has to be in the file: identifiers, weights and share counts

A holdings file is only as useful as its identifier columns, because identifiers are what let the file join to your positions, your prices and your risk model. Weights tell you the shape of the portfolio. Identifiers tell you what the portfolio actually is.

The minimum viable column set for institutional work:

Ticker-only files break in three predictable places. Dual listings collide, because the same ticker string on two venues is two securities. Share class changes and reorganisations reuse tickers, so a historical file joined on ticker alone will map to the wrong company. And non-US constituents in a global fund frequently have no clean US-style ticker at all.

AmericanETP includes Bloomberg FIGIs in its constituent list holdings files, which is the identifier that resolves the venue-level ambiguity a ticker cannot, and those fields sit alongside the standard columns in the same delivery. A separate fundamentals file carries the ETF description, leverage and the constituent count, which is the field you use to verify that a holdings file is complete rather than truncated.

Share counts deserve their own paragraph, because weights alone will not tell you whether a fund rebalanced. Weights drift every day with prices. Share counts only change when the portfolio manager acts, or when creation and redemption activity scales the basket. If your file has weights and no share counts, you cannot distinguish a rebalance from a rally, and the deeper mechanics of that distinction are covered in ETF Constituent Lists: 2026 Data Guide.

CSV download or API: which one fits the workflow?

Bulk CSV over FTP fits scheduled batch reconciliation, backtests and database loads. An API fits on-demand lookups inside an application, where a user or a service asks for one fund at a time and expects an answer in milliseconds. Most institutions end up needing both, but for different systems.

The failure modes are different in kind, not degree. An API fails through rate limits, pagination edge cases and partial responses: you request 3,000 funds, the 2,847th call returns a 429, and unless your client handles retry and backoff correctly you have a database with a hole in it that nothing will flag. A bulk file fails through non-arrival, truncation and silent schema change, which is why file arrival monitoring and a checksum or row-count assertion belong in the pipeline before anything else does.

Batch has one structural advantage worth stating plainly: the file is a fixed artefact. You can store it, hash it, diff it against yesterday and reproduce exactly what you loaded six months later. An API response is only reproducible if you saved it, and most teams do not. The trade-offs across both delivery models are worked through in ETF Holdings Data API vs CSV Feeds.

FTP delivery matters more than it sounds in 2026, because it survives inside firewalled bank and exchange environments where outbound HTTPS to a new vendor domain requires a security review that takes months. AmericanETP offers FTP access alongside its downloads, which for some readers is the only reason a feed is deployable at all this quarter rather than next year.

How far back does the archive go, and why it decides your backtest

Point-in-time holdings history is the single most expensive dataset to reconstruct after the fact, because you cannot derive it from anything you have now. Current holdings tell you what a fund holds today. They tell you nothing about what it held in March 2014, and no amount of price data will recover it.

Survivorship bias enters through a specific mechanism that is easy to miss. A current-holdings file, by construction, contains only funds that still exist. Every ETF that closed, merged or delisted since your backtest start date is absent, and those are disproportionately the funds that performed badly. A sector-rotation study run on today's fund universe back to 2010 is not measuring the strategy, it is measuring the strategy applied only to the funds that survived it.

Here is the concrete version. Suppose a quant team backtests a rotation model that holds the four strongest of twenty sector ETFs, monthly, from January 2010. Run on today's list of live funds, the model shows a strong result. Run on the point-in-time universe including funds that closed along the way, several of the months in 2011 and 2015 have the model holding a fund that would be delisted within eighteen months, and the result moves materially. Neither run is wrong arithmetically. Only one of them describes a strategy that could have been executed.

AmericanETP keeps archived constituent list datafiles back to July 2009, which is the concrete reference point for how far a point-in-time reconstruction can reach without rebuilding it yourself.

The question to ask before trusting any history claim

Ask whether the archive is as-published or restated. An as-published archive contains the file exactly as it was distributed on that date, including the errors that were later corrected. A restated archive applies today's corrections and today's identifier mappings to historical records.

Both are legitimate products. As-published is what you need to reproduce a decision that was actually made with that data on that date, or to satisfy a compliance question about what the desk knew. Restated is cleaner for research. What you cannot do is use one and assume the other, and a vendor that will not answer the question directly has told you something.

The related question is how corporate actions were handled. A constituent change report that identifies additions, deletions and share count changes between two dates saves you from inferring them by diffing files and misreading a ticker change as a trade.

Where each ETF holdings database fits in 2026

The honest comparison is about positioning and workflow shape, not about numbers, because pricing and feature pages change and a stale figure attributed to a named company is worse than no figure. Where a specific claim below comes from a provider's own page, the source and the date it was read are attached to that claim. Where nothing could be verified that way, the point is named as unverified.

etf.com's stock holdings tool. As read on etf.com's own tool page on 7 September 2026, the tool is described as a way to find which ETFs hold a given stock. That is a reverse lookup, and it is genuinely the right instrument when your question starts with a company rather than a fund. If you are assessing crowding in a single name across the ETF complex, starting from a bulk constituent feed means writing the join yourself.

ETF Database Pro. As read on ETF Database's own Pro page on 7 September 2026, the page states that its content and tools are exclusive to Pro members. The product is presented for active investors doing fund-level research rather than for batch data delivery, and evaluating it as a bulk feed is unfair to it. Whether its research framing and screening workflow suit your team is something to judge from the product itself; that is not a claim this article can source.

Nasdaq Data Link's ETF Constituents dataset. As read on Nasdaq Data Link's own dataset page on 7 September 2026, the dataset is described around actual holdings, including cash, derivative and short positions. That framing matters, because the funds where the cash and derivative lines are the interesting part are exactly the funds where thin files mislead. If you already consume other datasets through that platform, the marginal integration cost is close to zero, which is a real advantage.

Finnworlds. Finnworlds appears in searches for programmatic holdings data, but no dated source for its current delivery model, coverage or endpoints was available for this article, so treat any specific claim about it as unverified until you read its own documentation. The general point still holds: where holdings are fetched per request inside a user-facing feature, an API-shaped product fits that architecture better than a nightly bulk file does.

FactSet, Refinitiv, Morningstar and S&P Global Market Intelligence all carry holdings data inside much broader platforms. Their genuine advantage is breadth and entity linkage: holdings sitting next to ownership, estimates, fundamentals, and a supported symbology layer, with client service attached. If your firm already runs one of them, adding a separate holdings feed needs a reason. The trade-off is that you are buying and integrating a platform, with the procurement cycle and seat model that implies, and the enterprise end of that decision is unpacked in FactSet Pricing: What It Costs in 2026 and FactSet Alternatives: 2026 Options.

AmericanETP sits in the narrow band: bulk constituent files for ETFs and indexes, twice daily, with FIGIs and a deep archive, delivered as files over FTP. It does not attempt to be a research terminal. Founded in the 1990s as MasterDATA, and renamed to avoid confusion with IBM's use of that term, it predates most of the vendors it is now compared against, which is mostly relevant because the archive depth is a consequence of that.

Coverage: how many funds and indexes does the download include?

Coverage count is the first number to check and the easiest to misread, because three different universes get quoted in the same unit. "US-listed ETFs" is one population. "Global ETPs", including ETNs and non-US-listed products, is a much larger one. "Underlying index constituents" is a third thing entirely and is not a fund count at all.

A vendor quoting a large number is not necessarily quoting the number you need. Ask which of the three it is, and whether index constituent lists are included or sold separately.

AmericanETP covers 3,878 US and global indexes and US-traded ETFs. The reason index constituents alongside ETF holdings matters is tracking-difference work: to attribute a fund's deviation from its benchmark you need both sides of the comparison sourced consistently, on the same as-of date, with the same identifiers. Sourcing the fund from one vendor and the index from another introduces mapping differences that look exactly like tracking error.

Index coverage is also what makes derived analytics possible without a second subscription. Building sector exposure across a book requires a consistent classification applied across funds, which is the subject of ETF List by Sector: 2026 Classification Guide, and constructing an aggregate valuation series requires constituent-level fundamentals, which is worked through in Build the P/E Ratio S&P 500.

A reconciliation checklist for the first week of a new feed

Run these checks daily for the first two weeks of any new holdings feed, then keep them as permanent assertions in the pipeline. They catch the failures that are silent, which are the ones that cost money.

1. Verify weights sum within tolerance. For each fund, sum the weight column. Anything outside roughly 99.5% to 100.5% needs a look. A sum of 99.6% almost always means a cash line was dropped, not that the fund is 0.4% unallocated.
2. Count constituents against the fundamentals file. The holdings row count per fund should match the constituent count in the fundamentals file. A mismatch means truncation, and truncation at the tail of a file looks exactly like a fund that holds fewer small positions than it does.
3. Check for missing identifiers. Count rows where CUSIP, ISIN and FIGI are all null. Cash and some derivative lines legitimately lack a security identifier, so establish the expected null rate in week one and alert on deviation, not on presence.
4. Confirm cash and derivative lines survived ingestion. Load your parsed table and compare its row count to the raw file row count. Parsers frequently discard rows they cannot map to an equity master.
5. Diff two consecutive days for implausible turnover. Compute the share-count change per constituent. A broad index tracker showing 60% of positions changing overnight is a data problem, not a rebalance. Full replacement of the constituent list on a non-rebalance date is the classic signature of a vendor-side identifier remap.
6. Log file arrival times against the stated schedule. Record the timestamp of every arrival and compare against the published cadence, in AmericanETP's case the 6pm EST primary and the midday secondary run. Two weeks of timestamps tells you what your batch window actually is.
7. Store the raw file before parsing. Hash it, keep it, and never overwrite. When a discrepancy surfaces four months from now, the only way to prove whether the vendor or your loader introduced it is the original bytes.

What a daily holdings feed costs, and how to budget it

AmericanETP's pricing, as confirmed by a customer, is $1,500 per year or $150 per month for an individual, and $2,500 per year or $250 per month firm-wide. That is the full price list, and the firm-wide tier is the relevant one for a team rather than a single analyst.

Competitor pricing is deliberately absent from this article. The enterprise platforms do not publish per-seat figures in a form that can be verified from a public page, and quoting a remembered number for a named vendor is a liability rather than a service. What can be said is that terminal-class products are sold on negotiated multi-seat contracts with procurement attached, and the shape of that decision is covered in FactSet Pricing: What It Costs in 2026.

The real budget question is build versus buy, and it is usually answered wrongly. Scraping issuer sites for daily holdings is free, and it works, until an issuer changes a page layout or a file schema on a Tuesday and your Wednesday reconciliation runs on stale data without failing loudly. The cost of that arrangement is not the scraper, it is the engineer who owns it and the incident when it breaks quietly.

Three questions size the decision honestly. How many funds do you need, every day, without exception? How far back does your research need to reach, and could you reconstruct that history at any price if you started today? And how much engineering time does the alternative consume per year, priced at what your engineers actually cost?

FAQ

Where can I see all holdings of an ETF?

Every US-listed ETF issuer publishes the fund's holdings on its own product page, and that is the primary source. For a single fund on a single day, the issuer page is authoritative and free. The limitation is scale and history: issuer pages give you one fund, in the format that issuer chose, usually without a deep archive, which is why anyone tracking hundreds of funds moves to a normalised bulk feed.

How do I download ETF holdings as a CSV every day?

For a handful of funds, schedule a job that fetches each issuer's published file and normalises the columns yourself. For a large universe, subscribe to a bulk constituent feed that publishes one normalised set of files on a fixed schedule and collect them over FTP or HTTPS. The practical difference is maintenance: issuer scraping means you own every schema change across every issuer, whereas a feed means you own one schema and one arrival check.

Do ETF issuers publish full daily holdings, and how current are they?

Most US-listed ETFs disclose full portfolio holdings daily, which is one of the structural differences between ETFs and traditional mutual funds. The disclosed portfolio reflects the prior close, not the current session, so a file you read on Tuesday morning describes Monday's positions. Actively managed non-transparent and semi-transparent ETFs are the exception, publishing a proxy or delayed portfolio instead of the full daily list.

How far back can I get historical ETF holdings data?

That depends entirely on when the vendor started archiving, because point-in-time holdings cannot be reconstructed retroactively from current data. AmericanETP maintains archived constituent list datafiles back to July 2009. Before trusting any history claim, ask whether the files are as-published or restated, since the two answer different questions and are not interchangeable for compliance work.

What is the difference between an ETF holdings database and an ETF holdings API?

A database delivers a complete set of files on a schedule, designed to be loaded in bulk and stored. An API answers individual queries on demand, one fund or one security at a time. Batch delivery suits reconciliation, backtesting and warehouse loads because the artefact is fixed and reproducible; an API suits application features where a user triggers the request. The comparison is developed further in ETF Holdings Data API vs CSV Feeds.

Are ETF holdings downloads free anywhere?

Yes, at the single-fund level. Issuer product pages publish daily holdings at no cost, and several public tools let you look up which funds hold a given stock. Free breaks down on three axes: breadth across thousands of funds, depth of point-in-time history, and identifier completeness, since free files rarely carry CUSIP, ISIN and FIGI together. Those three gaps are what paid feeds are actually selling.

If you are evaluating a daily constituent feed against the checklist above, the file structure, identifier columns and archive depth are the things to test first. See what the files contain and how they are delivered at americanetp.com.