ETF Constituent Lists: 2026 Data Guide

An ETF constituent list is a dated file listing every security a fund holds on a given day, with each position's weight, share or par quantity, and its identifiers. That single sentence hides most of the work. The file is a data artefact with a schema, a provenance chain, a publication lag and a set of failure modes, and almost none of the pages that rank for this term treat it that way.

This guide covers what the file contains field by field, why two vendors publishing the same fund on the same date disagree, how identifier mapping and missing point-in-time history quietly corrupt backtests, and the checks worth running before a constituent feed goes into production.

What is an ETF constituent list?

An ETF constituent list is a dated file listing every security a fund holds, with weight, share or par quantity, and identifiers for each line. It is a snapshot of a portfolio at a stated as-of date, not a description of a strategy.

Three documents get conflated. A constituent list describes what a fund actually holds. An index membership list describes what an index says should be held, which is the benchmark, not the portfolio. A fund fact sheet is a marketing document summarising both, usually to two decimal places and usually a month old.

The distinction matters because the three diverge in predictable ways. An optimised or sampled fund tracking a broad index may hold a few hundred of several thousand index members. An active ETF changes holdings on any trading day. A full-replication index fund holds close to the membership list and changes materially only at rebalance, plus the drift from corporate actions and creation and redemption flow in between.

So the answer to "how often do constituents change" depends entirely on the fund. Daily for active and optimised products, and effectively only at rebalance dates for full replication. A feed that treats both cases the same is fine; a research process that assumes one shape for everything is not.

What fields does a constituent file actually contain?

A typical constituent holdings row carries an as-of date, the fund's ticker, an identifier set for the held security, the security name, weight, shares or par held, market value, and classification fields for sector, country, currency and asset class. Some of those fields come straight from the issuer. Others are computed by the vendor, and the two categories fail differently.

Derived weights drift from issuer-published weights for mundane reasons. The vendor may price at a different time, may exclude cash from the denominator, may round to four decimal places instead of six, or may value a futures leg at notional where the issuer values it at margin. None of these is an error. All of them produce two files that look wrong next to each other.

AmericanETP includes Bloomberg FIGIs in the constituent holdings files, which removes the most common join problem before it starts, and ships a separate fundamentals file carrying the ETF description, leverage and constituent counts. The constituent count in that second file is useful beyond documentation: it is a free integrity check against the row count in the holdings file, which is the first item on the validation checklist later in this article. The Bloomberg Extensions page describes the identifier fields in more detail.

Where do constituent lists come from, and why do vendors disagree?

Constituent data has three distinct origins: issuer disclosure files published by the fund sponsor, index membership files published by the index provider, and vendor-normalised feeds that clean, map and republish one or both. Disagreement between two vendors on the same fund and the same date is usually a normalisation difference, not a data error.

The recurring causes are worth knowing by name, because each produces a different symptom:

• Cash and collateral rows. One vendor emits a cash line as a constituent; another drops it and rescales the remaining weights. Holdings counts differ by one, weights differ by tens of basis points across every row.
• Futures and swap legs. Synthetic and leveraged products hold derivative positions. Notional versus market value treatment changes both count and weight materially.
• Unsettled trades. A fund that traded yesterday may disclose the target position or the settled position depending on the sponsor's convention.
• Rounding. Weights published to two decimals will not sum to 100 across 500 rows. Weights recomputed from shares and price will not match the published ones either.
• Disclosure timing. A file dated today may reflect positions as of yesterday's close. Two vendors reading the same issuer file can stamp it differently.

The practical guidance is unglamorous: pick one source of record per use case and stay on it. Blending two constituent feeds to fill gaps produces a portfolio that never existed, with a holdings count that matches neither vendor and weights that sum to something arbitrary. If you need cross-checks, run them as comparisons and log the differences, rather than merging.

That choice interacts with delivery shape, since a per-symbol API and a bulk dated file encourage different habits. The trade-offs are covered in ETF Holdings Data API vs CSV Feeds.

How often should ETF holdings data update?

For most institutional workflows, once per business day after the close is the meaningful cadence, with an intraday refresh useful mainly for catching corrections and late-arriving issuer files. Anything faster is constrained by the issuer, not the vendor: a fund that discloses once a day cannot be republished more freshly than it was disclosed.

There are two clocks and they are not the same. Issuer disclosure cadence governs when the underlying truth changes. Vendor publication cadence governs when you can see it. A file that a vendor published at 6pm today may carry an as-of date of today and still reflect positions held at yesterday's close, because that is what the sponsor disclosed.

AmericanETP updates constituent lists twice daily, with a primary run at 6pm EST and a secondary run at roughly noon EST. The primary run is the one research pipelines should key off. The secondary run's real value is corrections: an issuer file that arrived late or was restated does not have to wait a full day to reach your warehouse. The Downloads page shows the file layout that both runs write to.

Extended and near-continuous trading complicates the as-of stamp rather than the cadence. When a security trades outside the traditional session, "close" stops being a single unambiguous instant, and a constituent file's market values become a statement about a chosen snapshot time. 24×5 Trading: What It Breaks in Data covers what that does to timestamped datasets more broadly.

Why point-in-time history matters more than current holdings

Current holdings answer one question: what is this fund exposed to now. Only a point-in-time archive answers the question research actually asks, which is what a strategy would have held on a past date, given only what was knowable then. Re-downloading a fund's current constituent file to reconstruct a 2014 portfolio does not approximate history, it fabricates it.

Consider a concrete case. A broad US equity ETF held Twitter through 2021. The company was taken private in 2022 and the listing disappeared. Download that fund's current constituent file today and there is no Twitter row, no gap, no warning: the position simply never existed as far as the file is concerned. Backtest a 2021 strategy on that file and you have quietly assumed the fund only ever held companies that survived to 2026, which is survivorship bias in its purest form.

Reconstitution bias is the same failure at index level. A fund's membership turns over at every rebalance, and today's list is the accumulated result of every add and drop since inception. Corporate actions compound it: spin-offs, mergers and share class changes rewrite identifiers, and tickers get reused by unrelated companies years after a delisting, so a naive ticker join to a modern price file can attach the wrong company's returns to a historical position.

AmericanETP keeps archived constituent list datafiles back to July 2009, which is the practical floor for a US ETF study with meaningful cross-sectional breadth. Start dates vary across the category and are not something to assume: ask each vendor for the earliest as-of date it can actually deliver, and test it by pulling a file from that date rather than reading a coverage page. The Constituent Change Report is the add and drop view of the same history.

Identifier mapping: FIGI, CUSIP, ISIN and ticker

Ticker is the worst available join key for constituent data, because it is not unique across exchanges, not stable through corporate actions, and reusable after a delisting. Join on a permanent identifier instead, and treat every unmapped row as an incident rather than a rounding error.

The identifier types each solve a different part of the problem:

• FIGI comes in levels. A share class FIGI groups all listings of a share class, a composite FIGI groups listings within a country, and an exchange-level FIGI identifies one listing. Joining at the wrong level either fragments one company into several rows or collapses two share classes into one.
• ISIN is issued nationally and gives good coverage for non-US lines, which is where ticker joins fail worst. It does not distinguish trading venue on its own.
• CUSIP is well established for North American securities and is a licensed identifier, so redistribution and downstream use carry terms that a data team should confirm before building a pipeline on it.
• Ticker is for humans reading a report.

Here is the arithmetic that makes the point, using a constructed illustration rather than a real file. Take a 503-row constituent list for a large-cap fund and join it to a security master on ticker alone. Twelve rows fail: two dual share classes that resolved to the same ticker root, three foreign lines whose local tickers collide with US ones, four names changed since the last master refresh, and three cash and futures rows with no ticker at all.

Twelve failures out of 503 sounds tolerable until you look at what they weigh. If those twelve rows carry 4.1% of the fund by weight and your pipeline discards unmapped rows silently, every aggregate you compute from that file is understated by 4.1% and nothing in the output says so. This is the single most common way a constituent pipeline produces confident, wrong numbers. Log unmapped rows, count them daily, and alert on the weight they represent rather than the row count. Classification joins have the same failure profile, covered in ETF List by Sector: 2026 Classification Guide.

Sector weights and the 11 GICS sectors

A sector weight is the sum of constituent weights sharing a sector label, divided by the total weight in the denominator you chose. Both halves of that sentence are decisions, and different vendors make them differently, which is why a fund's published sector breakdown rarely matches one you compute yourself.

GICS defines 11 sectors at its top level: energy, materials, industrials, consumer discretionary, consumer staples, health care, financials, information technology, communication services, utilities and real estate. Most institutional reporting is built on that framework, but it is not the only scheme in use, and a vendor's own classification can assign a company differently at the margin. Payment processors and large platform companies are the usual disputed cases.

The denominator is the quieter problem. If a fund holds 0.8% cash and you exclude the cash row, every sector weight you compute is scaled up by a factor of about 1.008, which is enough to break a reconciliation against a published breakdown that included it. Decide once whether cash sits in the denominator, document it, and apply it everywhere.

The same principle governs any constituent-level aggregate, not just sectors. PE of S&P 500: Why the Numbers Disagree walks through the version of this problem where the aggregation choice changes the headline number more than the input data does.

Building fundamentals and index aggregates from constituents

A constituent list is an input, not an output. Once you have dated weights and reliable identifiers, the file supports weighted fundamentals, breadth measures, fund overlap, crowding analysis and index replication cost, none of which any fact sheet publishes.

The common constructions are straightforward in principle:

• Weighted fundamentals. Join constituents to a fundamentals table and aggregate P/E, yield or leverage by weight. The aggregation method dominates the result.
• Breadth. Count constituents above a moving average or with positive returns, over the point-in-time membership rather than today's.
• Overlap. Intersect two funds' constituent sets by identifier and sum the minimum weight per shared name. This is the number that tells an allocator whether two holdings are actually one.
• Replication cost. Compare the constituent set to what you can trade, using shares held and free float to estimate the tail of illiquid names.

The overlap calculation is the one most often done wrong, because it is usually done on ticker and usually done on current files for both funds. Both errors push the answer in the same direction, understating true overlap, which is exactly the direction a risk report should not err in.

For the weighted-fundamentals case, Build the P/E Ratio S&P 500 works through the arithmetic end to end and shows why harmonic and arithmetic aggregation of the same constituent file produce materially different answers.

CSV and FTP delivery versus a REST API

Neither delivery shape is better in general. A REST API suits per-symbol lookups inside a live application, where you need one fund's holdings on demand and low latency matters. Bulk dated files suit research, backtests and warehouse loads, where you need every fund for a date range and reproducibility matters more than latency.

The distinction is really about how you plan to reload. A dated CSV is idempotent by construction: the file for a given date does not change, so re-running yesterday's load produces yesterday's result. Reconstructing the same guarantee over an API means paginating thousands of symbols, handling partial failures midway, and hoping the endpoint returns the same values it returned last week.

Vendors position accordingly. Some build the product around a queryable endpoint returning one fund's holdings at a time, which is a natural fit for an application that asks about a single symbol on demand. AmericanETP delivers CSV files with FTP access, which is a natural fit for a nightly load into a research warehouse. Neither positioning is a criticism of the other; they are answers to different questions.

If you take the file route, file naming discipline is what makes reloads safe. A name carrying the fund or index identifier and the as-of date, with one file per date, lets a pipeline detect gaps, replay a range and prove which version of the data produced a given result. ETF Holdings Data API vs CSV Feeds covers the trade-offs in more depth.

Coverage: how many ETFs and indexes does a feed need to carry?

Coverage claims are hard to compare because vendors count different things. A count of listings is not a count of funds, a count of funds is not a count of share classes, and index membership coverage is a different dataset from ETF holdings coverage. Ask which unit is being counted before comparing two numbers.

AmericanETP covers 3,878 US and global indexes and US-traded ETFs, which is a combined count of indexes and funds rather than a count of listings. Another vendor's headline may count listings, share classes or index memberships alone, and none of those numbers is directly comparable to the others. That is precisely the point: a headline count only means something once you know its unit.

The other coverage question is what you can do with it. Browsable ETF directories are genuinely good at discovery: filtering, screening and reading about a fund before you commit to it. What a web directory is not is a deliverable dataset, and building a pipeline on one means parsing pages designed to be read by people, with no as-of stamping and no guarantee the same query returns the same rows next month.

For a research or production workflow, judge coverage by three things: whether the universe includes the funds you actually trade, whether index membership is available alongside ETF holdings, and whether history goes back far enough for the study you want to run. A large number with a shallow archive is worth less than a smaller one with sixteen years behind it.

What ETF constituent data costs

AmericanETP publishes its pricing: $1,500 per year or $150 per month for an individual, and $2,500 per year or $250 per month firm-wide. That is checkable, which is the relevant property here.

Most of the enterprise market is not. FactSet, Refinitiv, Morningstar, S&P Global Market Intelligence and ETF Global do not publish per-seat constituent data pricing on their public pages, so any specific figure you find quoted for them elsewhere is unverified by the vendor. Treat those numbers as anecdote, and get a quote scoped to your actual use, redistribution rights and seat count. FactSet Pricing: What It Costs in 2026 discusses what can and cannot be established from public sources.

That opacity is not automatically a criticism. Enterprise contracts bundle entitlements, redistribution rights, support and coverage well beyond ETF constituents, and a per-seat number would not describe them usefully. It does mean budget comparisons across the category require a procurement process rather than a search.

One point of context on the vendor landscape: AmericanETP, originally MasterDATA, was founded in the 1990s and predates most current ETF data competitors. That matters mainly because archive depth is a function of when a firm started keeping files, not of when it started selling them.

A validation checklist before a constituent feed goes to production

Run these nine checks on every load, not once during evaluation. Most constituent data failures are silent, and the ones that are not silent are usually caught by the cheapest check in the list.

1. Weights sum within tolerance. Define the tolerance explicitly, allow for rounding and cash, and alert when a fund drifts outside it.
2. Constituent count matches the fundamentals file. The row count in the holdings file should reconcile with the count published alongside it.
3. No duplicate identifiers within a fund and date. Duplicates usually mean a share class or listing-level mapping problem.
4. As-of date advances on every business day. A stale file that reloads cleanly is worse than a missing one, because nothing fails.
5. Corporate action days reconcile. On a known split or merger date, confirm shares held and identifiers moved as expected.
6. Cash and derivative rows are flagged, not dropped. Dropping them changes every weight in the file and leaves no trace.
7. Unmapped identifiers are logged with their weight. Alert on the weight of unmapped rows, not the count.
8. Archive replays reproduce a known past date. Pick a date you have already analysed and confirm the pipeline reproduces it exactly.
9. Two-vendor spot check on three funds per quarter. Compare, log the differences, and understand each one. Do not merge.

The last check is the one teams skip and later regret. Differences between vendors are informative even when neither is wrong, because they tell you which normalisation decisions your downstream numbers depend on.

FAQ

What are the constituents of an ETF?

The constituents of an ETF are the individual securities the fund holds, each with a quantity, a weight in the portfolio and a set of identifiers. For a full-replication index fund the constituents closely track the index membership list; for a sampled, optimised or active fund they can differ substantially from any published benchmark.

What are the 11 ETF sectors?

The 11 sectors in the GICS framework are energy, materials, industrials, consumer discretionary, consumer staples, health care, financials, information technology, communication services, utilities and real estate. A fund's sector weights are computed by summing constituent weights within each sector, so results depend on which classification scheme the vendor uses and whether cash is included in the denominator. ETF List by Sector: 2026 Classification Guide covers the classification joins in detail.

Can you get a list of ETFs that invest in commodities?

Yes, and there are two ways to build one that give different answers. Filtering on a fund's stated category returns products that describe themselves as commodity funds; filtering on constituent data returns funds whose actual holdings include commodity futures, physical metals or commodity-linked notes, which catches multi-asset funds the first method misses. The constituent-driven approach requires an asset class flag on each holdings row, which is why that field matters more than it looks.

What is the 7% rule in ETFs?

There is no single, standardised "7% rule" for ETFs, and the phrase is used loosely for several unrelated things, including position-size caps in concentrated portfolios and diversification constraints under fund regulation. If you need the actual constraint that applies to a specific fund, read its prospectus, then verify the resulting concentration directly from the constituent file rather than from a rule of thumb.

How do I download daily ETF holdings?

Daily ETF holdings are downloaded either as bulk dated files, typically CSV over FTP or HTTPS, or by querying a per-symbol API. Bulk files suit warehouse loads and backtests because each dated file is stable and reloads idempotently; APIs suit applications that need one fund's holdings on demand. AmericanETP publishes constituent files twice daily, with a primary update at 6pm EST and a secondary update at roughly noon EST.

How far back do ETF constituent archives go?

Practical US ETF constituent archives generally begin around 2009, since that is when broad daily holdings disclosure became consistent enough to keep. AmericanETP keeps archived constituent list datafiles back to July 2009. Anything earlier tends to be thin in cross-section, and current holdings files should never be substituted for archived ones, since doing so introduces survivorship and reconstitution bias into every result.

If you are evaluating a constituent feed against the checklist above, the fastest way to test it is on your own funds and your own dates. See file layouts and coverage at AmericanETP, or get in touch with the specific funds and history window you need to validate.