ETF Constituents Data: Sources and Formats 2026

What is ETF constituents data?

ETF constituents data is a dated list of the securities an ETF or index holds, with identifiers and weights. For a professional user it is a reference table that other systems join to: portfolio exposure, overlap, benchmarking, index replication checks and risk models all start from it.

This article uses "holdings" as the working term for the securities inside a fund. The phrase "constituents" is the older index-world word, and it is still what most people type into a search box, which is why it appears in the title. A deeper walkthrough of the terminology and the access routes sits in ETF constituents: how to get holdings data.

How do ETF holdings differ from index constituents?

ETF holdings describe what a fund actually owns on a given date. Index constituents describe what a benchmark's rulebook says should be in the index on that date. The two usually overlap closely, but they are not the same file, and the gap between them is where tracking difference lives.

A fund that samples an index will hold fewer names than the index contains. A fund that uses swaps or derivatives may hold collateral and cash instruments rather than the index names. A data buyer who treats the two as interchangeable will misstate exposure for exactly the funds where the distinction matters.

What is not constituents data?

Fundamentals and fund flows are separate datasets. Fundamentals describe the fund itself: a description, leverage factor, the number of holdings. Fund flows describe creations and redemptions, shares outstanding and assets over time. Neither tells you what is inside the fund, though a fundamentals file is often the right companion because it lets you sanity check a holdings file against a stated holdings count.

What fields should an ETF holdings file contain?

A usable holdings file carries, at minimum, the fund identifier, an as-of date, a security name, a security ticker, a weight, a share count and a stable security identifier. Without the last of these, the file works for reading and fails for joining.

The table below lists the fields a professional user should look for and why each matters. Of these, the only field this article states as confirmed in AmericanETP's holdings files is the Bloomberg FIGI. Treat the table as a requirements list to check against any sample file, including ours, before you build on it.

Field Why a professional user needs it
Fund ticker Keys the file to the fund. Needed for every join to a fund master.
As-of date Separates the date the holdings describe from the date you received the file. Essential for history.
Security name Human review and fuzzy matching when identifiers are missing.
Security ticker Convenient for display and quick lookups, unreliable as a join key over time.
Weight Drives exposure, overlap and look-through calculations.
Shares held Allows reconstruction of market value and detection of weight drift.
Bloomberg FIGI Security level identifier intended to stay attached to the instrument across ticker changes.
Asset type or class Separates equities from cash, derivatives and fixed income lines.

Why do ticker-only files break joins?

Tickers are reused, changed and retired. When a company changes its ticker, any system joining on the old ticker loses the link between pre and post change history. The company did not change. The label did.

The same failure appears with mergers, spin-offs, share class changes and tickers reassigned to unrelated companies years later. A security level identifier such as the Bloomberg FIGI is intended to stay attached to the instrument rather than to a label. Joining on FIGI and keeping the ticker as a display field removes a whole category of silent errors.

What does the fundamentals file add?

AmericanETP provides a fundamentals file with the ETF description, leverage and holdings counts. Its main job in a pipeline is validation and filtering. If the fundamentals file says a fund has a stated number of holdings and the holdings file has a different number of rows, you have found something to investigate before it reaches a model.

The leverage field matters for a more specific reason. A 2x or inverse fund's weights do not describe economic exposure the way an unleveraged fund's do, and an exposure calculation that ignores the leverage factor will be wrong by construction.

How often is ETF holdings data updated, and when does it arrive?

Holdings data has three timestamps that are routinely confused: when the issuer publishes, the as-of date the file describes, and when a vendor delivers it to you. AmericanETP updates twice daily, with a primary update at 6pm EST and a secondary update at about noon EST.

Issuer publication schedules differ by sponsor and by fund type, and the as-of date on a published file frequently refers to the prior trading day. Check the sponsor's own page for any fund where timing matters rather than assuming a standard.

Why does the as-of date matter more than the delivery time?

A file received at 6pm that describes the previous close is a different object from a file received at 6pm that describes today's close. If your system stores only the delivery date, you will misalign holdings with prices by a day, and the error will be small enough to go unnoticed in a backtest.

Store both dates. Use the as-of date to join to price history and the delivery date to audit what you could have known at the time.

Why does update timing affect exposure and overlap?

Consider an RIA running a $50 million sleeve split 60 percent to Fund A and 40 percent to Fund B. Suppose both hold the same stock, at 6 percent of Fund A and 4 percent of Fund B. Look-through exposure is 0.6 × 6 + 0.4 × 4 = 3.6 + 1.6 = 5.2 percent, or $2.6 million of the sleeve.

Now suppose Fund A rebalances and its weight in that stock moves to 8 percent while your file still shows 6. Your look-through becomes 0.6 × 8 + 0.4 × 4 = 6.4 percent, so the stale file understates the position by 1.2 percentage points, about $600,000 on this sleeve. The figures here are illustrative, but the arithmetic is the point: stale holdings translate directly into misreported concentration.

A second daily update narrows that window. For the mechanics of the twice-daily schedule see daily ETF holdings data update, and for the question of which funds publish when, see ETF holdings data availability.

Where does ETF constituents data come from?

ETF constituents data comes from five broad places: issuer websites, exchange and index provider files, platform-embedded datasets, screeners, and commercial vendor files. Each is built for a different user, and the right one depends on whether you need a single lookup or a repeatable, auditable load.

None of the descriptions below quotes feature lists or limits from specific products. Those change, and you should confirm them on each provider's own pages.

Issuer websites

Issuers publish holdings for their own funds, usually as downloadable files on each fund page. This is the primary source for any single fund, and it is the reference you reconcile everything else against. The cost is operational: formats differ by sponsor, URLs change, and collecting thousands of funds this way is a data engineering project of its own.

Exchange and index provider files

Index providers publish constituents and weights for their benchmarks, and exchanges publish reference data for listed products. These describe the index, not the fund, so they answer a different question from an issuer holdings file. They are valuable for replication and tracking difference work, and access terms vary by provider.

Platforms and screeners

Research platforms and screeners can put holdings in front of you without any data engineering. If your job is to explore a fund, build a universe inside a backtesting environment or check a handful of funds, they may be the faster route, and for that use they can win on convenience.

The questions to ask are about control. Confirm the schema the platform uses, its update timing and its history depth, and whether the same data can be exported into an in-house warehouse or a client reporting system.

Commercial vendor files

Vendors deliver holdings as files or through programmatic access. Scope, delivery formats, update times and terms differ by vendor, and each should be confirmed on that vendor's own pages. Large multi-asset providers such as FactSet, Refinitiv, Morningstar and S&P Global Market Intelligence, and ETF-focused providers such as ETF Global, are all candidates to compare on those points.

AmericanETP sits in the narrower category: holdings and fundamentals as CSV files with a defined update schedule. For vendor comparisons, see the ETF Global review and ETF Global vs Morningstar.

CSV files, API or FTP: which delivery format fits?

Bulk CSV suits full-universe loads on a schedule, an API suits on-demand lookups of a few funds, and FTP suits automated pickup of files without anyone logging in. AmericanETP delivers CSV files, with FTP access available. The API row in the table below describes a general delivery pattern, not an AmericanETP feature.

The decision depends on how your system consumes the data, not on which format is more modern.

Delivery Best for Main trade-off
Bulk CSV Loading the whole universe into a warehouse each day You receive everything, including funds you do not need
API Looking up one fund at request time in an application Rate handling, authentication and full-universe pulls become your problem
FTP Scheduled, unattended pickup into batch pipelines Needs file monitoring and a way to detect late or missing files

When is CSV the better fit?

Quant funds and banks typically run a nightly job that loads every holding for every fund into a database and then queries it many times. For that workload, one file per update is simpler than thousands of API calls, and it gives you a record of exactly what was delivered. You can diff today's file against yesterday's and archive both.

When is an API the better fit?

A fintech team building a product screen that shows a fund's top ten holdings on demand does not need the full universe in a table. An API returns exactly what the user asked for. The cost is dependence on someone else's uptime and rate limits at request time. The trade-offs are covered in more depth in ETF holdings data API vs CSV and ETF API: holdings data compared.

Where does FTP fit?

FTP is unglamorous and reliable for batch work. A scheduled job fetches the new files after an update window and drops them into storage, with no application code calling an endpoint. Pair it with a check that the expected file exists for the expected date, because a missing file is the failure mode that is easiest to miss.

How much history does ETF holdings data need for backtesting?

Backtests need holdings as they were on each historical date, not as they are today. If only current holdings exist, the backtest sees only the funds and securities that survived, which inflates results. AmericanETP archives holdings files back to July 2009.

Two problems make current-only data dangerous. Survivorship bias removes funds that closed and securities that were delisted. Point-in-time bias applies today's weights to yesterday's decision, so a strategy appears to know what a fund would hold years later.

What does a 2009 start date cover?

July 2009 gives a sample that includes the post-financial-crisis recovery, multiple rate regimes and the growth of leveraged and sector products. A shorter archive limits the number of regimes a strategy is tested through, and it affects statistics such as drawdown and turnover more than most users expect. The specific number of funds present on any one historical date should be checked in the archive itself rather than assumed.

What should you check in any archive?

Four checks catch most problems:

  • Gaps: count files per month and look for missing dates, especially around holidays and early closes.
  • Delisted funds: confirm that funds which closed still have their historical files, rather than disappearing from the archive.
  • Restated files: find out whether a past file was ever overwritten, since a silently corrected file changes the historical record you tested against.
  • Identifier consistency: check that the same security carries the same identifier across years, so your joins do not fracture at a corporate action.

How do you evaluate an ETF holdings database before buying?

Evaluate a holdings database against six criteria: universe coverage, identifiers, update times, archive depth, delivery method and file stability. Then run a sample-file test that reconciles weights and compares several funds to issuer files.

For reference, AmericanETP covers 3878 US and global indexes and US-traded ETFs. For a longer discussion of what makes a list usable, see ETF constituent lists: a data guide.

What belongs on the checklist?

  • Coverage: does the universe include the funds and indexes you hold or report on, including non-US indexes if your mandate needs them?
  • Identifiers: which security identifiers are present, and are they stable across time?
  • Update times: when does each daily update land, and what is the as-of date relative to delivery?
  • Archive depth: how far back do files go, and are they complete?
  • Delivery method: does it match how your systems consume data, whether CSV, FTP or an API?
  • File stability: do column names, order and formats stay the same between deliveries?

What does a sample-file test look like?

Request a sample and run these checks before committing engineering time.

  1. Sum the weights for every fund and flag any that do not land near 100 percent. Cash and derivative lines often explain the gap, but you need to know which.
  2. Pick five to ten funds and compare the holdings to the issuer's own file for the same date. Differences in row count and weights tell you how the vendor processes source data.
  3. Include a leveraged fund and a fixed income fund. Both test the edges of a schema: leverage affects how weights are interpreted, and bonds often lack the equity-style tickers that simple files assume.
  4. Join the file to a security master on FIGI and on ticker separately, then compare match rates.
  5. Compare the stated holdings count in the fundamentals file with the row count in the holdings file.

For a view of how fund universes differ by geography, global ETF list by holdings is a useful companion.

What does ETF constituents data cost?

AmericanETP pricing is $1500 per year or $150 per month for an individual, and $2500 per year or $250 per month firm-wide. These are the confirmed figures, and the current terms are on the Downloads page.

This article does not quote other vendors' prices. Pricing pages change, many enterprise vendors quote by conversation rather than publishing a figure, and an outdated number is worse than none. For what you can verify yourself, see ETF Global pricing.

Why does the company history matter to a data buyer?

AmericanETP was originally named MasterDATA and was founded in the 1990s, which predates most current ETF data competitors. The domain was renamed to AmericanETP to avoid confusion with IBM's use of the term. For a buyer, the relevant point is simply how long the company has operated. Consistency of the archive should be established with the sample-file test above, not inferred from company history.

Which use cases need constituents data, and which file serves each?

Each user type leans on a different part of the data: history and identifiers for quant funds, fresh weights for advisers, coverage for exchanges and vendors, and stable delivery for fintech teams.

  • Quant funds: need the archive and stable identifiers. Backtests depend on point-in-time holdings back to July 2009, and FIGI joins keep security history intact across ticker changes.
  • RIAs: need current weights and dependable timing for overlap and look-through exposure, as in the $2.6 million example above. The twice-daily update schedule matters most here.
  • Exchanges and data vendors: need broad reference coverage. AmericanETP covers 3878 US and global indexes and US-traded ETFs, and its fundamentals file carries descriptions, leverage and holdings counts. Whether that fits a given reference data process is something to test against your own records.
  • Fintech teams: need predictable file structure and a delivery method that fits their pipeline. Column stability and automated pickup via FTP matter more than any single field.
  • Banks and large institutions: need all of the above plus auditability, which depends on keeping dated files and archived history for model validation and reporting. As noted above, check whether any past file was ever restated.

Sector classification is a related need for almost every one of these users, and ETF list by sector covers how classification schemes differ and why that affects aggregation.

When does constituents data not apply?

Holdings data does not tell you intraday positions, since files are updated on a schedule rather than continuously. It does not describe fund flows, premiums and discounts or trading liquidity, which need separate datasets. And for non-transparent or semi-transparent fund structures, the holdings disclosed may be delayed or partial, so any exposure calculation should note that limitation.

FAQ

What is the difference between ETF holdings and ETF constituents?

In practice the terms are often used interchangeably, but there is a useful distinction. Holdings are what a fund owns on a given date. Constituents are conventionally the members of an index under its rules. A fund that samples its index, or uses derivatives, will have holdings that differ from the index constituents.

Where can I download ETF holdings data daily?

Issuers publish holdings for their own funds on their websites, and vendors aggregate them into single files. AmericanETP delivers holdings as CSV files with a primary update at 6pm EST and a secondary update at about noon EST, and FTP access is available. Current download options are on the Downloads page.

How far back does ETF constituents data go?

It depends on the source, so check how much history a given source provides before relying on it. AmericanETP archives constituent list data files back to July 2009. Whatever the source, check the archive for missing dates, delisted funds and restated files before relying on it for a backtest.

Does ETF holdings data include FIGIs or other identifiers?

AmericanETP holdings files include Bloomberg FIGIs. Identifiers matter because tickers change and are reused, so joins on ticker alone can fail silently. When evaluating any source, confirm which identifiers are present and whether they stay stable over time.

Is there an ETF holdings database available as CSV?

Yes. AmericanETP provides daily updated ETF and index holdings lists, fundamentals and identifiers as CSV files by subscription, covering 3878 US and global indexes and US-traded ETFs. Pricing is $1500 per year or $150 per month for an individual, and $2500 per year or $250 per month firm-wide. Questions can go through the Contact page.

To test the files against your own universe and identifiers, start at AmericanETP.

Leave a Reply

Your email address will not be published. Required fields are marked *