Fund data providers compared for developers (2026): Morningstar, Bloomberg, Refinitiv, market-data APIs and ISIN-first APIs

There are four ways to get fund and ETF data into an application: license an enterprise platform (Morningstar, Bloomberg, LSEG's Refinitiv and Lipper), use a stock-market data API and accept that it knows ETFs mostly as tickers with prices, read each fund's own published documents yourself, or call an ISIN-first fund data API that has already done the reading. Which one fits depends on six criteria: what data you need (prices versus factsheet content), coverage, freshness, how you identify funds, how you are allowed to use the data, and how the pricing scales. This post walks through those criteria without quoting competitor prices, because enterprise contracts are negotiated and anything printed here would be wrong for you.

Criterion 1: which data do you actually need?

"Fund data" hides two different datasets.

Market data is what trades: the price of an ETF share on an exchange, bid and ask, volume, intraday and historical. It exists only for listed products and varies by listing. It is the domain of exchanges and market-data vendors.

Factsheet data is what the fund discloses: fees, the risk indicator, holdings and exposures, NAV history and NAV-based returns, fund size, objective, benchmark, SFDR classification, and the identity of the share class. It exists for every fund, listed or not, and is published by the fund house in the factsheet, the PRIIPs KID, the prospectus and holdings and NAV files. The factsheet walkthrough lists the blocks.

Most product features people build (screeners, comparison pages, portfolio look-through, client reporting, compliance checks, AI assistants) need factsheet data; a trading screen needs market data. The NAV vs market price post explains why the two should not be mixed in one series. Decide which you need before comparing providers, because the categories below are strong in one and weak in the other.

Criterion 2: coverage and identifiers

Coverage has two dimensions: which funds, and which fields per fund. Enterprise platforms cover the largest number of funds worldwide, including many that publish little. Market-data APIs cover what is listed. Document-based approaches cover exactly the issuers whose documents they can read, but for those they return the full factsheet.

The identifier matters as much as the count. Funds are identified by ISIN per share class; tickers exist only for ETFs and differ per exchange. A provider whose primary key is the ticker will represent an ETF several times and a non-listed UCITS fund not at all. The identifiers post explains why ISIN is the right key, and the ISIN glossary entry has the format. Ask any provider: "can I look up a fund by ISIN, and does each share class come back separately?"

Criterion 3: freshness

Factsheet data changes on a daily-to-yearly cadence: NAV daily, holdings monthly or daily depending on the issuer, fees and the risk indicator from the KID a few times a year at most. A provider that refreshes daily is as fresh as the source. Intraday refresh only matters for market prices. The relevant questions are whether the provider gives you an as-of date per figure and whether it tells you when a tracked field changed. The freshness post goes through this in detail.

Criterion 4: licence and redistribution

This is where enterprise platforms and self-serve APIs differ most. Enterprise data licences typically distinguish internal use, display to clients, and redistribution, and price them differently; they also often restrict derived data. Read the terms before designing a product that shows the data to end users. Self-serve APIs state commercial-use rules per plan; document-based approaches inherit the terms of each issuer's site. Whichever route you take, budget legal time proportional to how public your use is.

Criterion 5: integration effort

Enterprise platforms integrate through their own SDKs, file deliveries, or terminal-bound APIs, and often expect a data team to manage the feed. Market-data APIs are simple REST. Reading documents yourself is a crawler, a PDF parser, a table extractor and a normaliser per issuer, plus monitoring for layout changes; the factsheet automation post and the build-your-own comparison describe that project honestly. ISIN-first APIs are one REST call with a JSON schema, usually with an OpenAPI spec and SDKs.

Criterion 6: pricing model

Three models exist: annual contracts priced per seat, per use case or per data set (enterprise); monthly subscriptions with request quotas (market-data APIs, ISIN-first APIs); and your own engineering time (do it yourself). Contracts scale with your organisation; quotas scale with usage; engineering time scales with the number of issuers and document formats you support. Enterprise prices are not published and vary by deal, so a comparison table with numbers in it is fiction. What can be compared is the shape: fixed annual commitment versus pay-as-you-grow.

The comparison

The per-provider pages (Morningstar, Bloomberg, LSEG Refinitiv and Lipper, stock-market APIs) go into where each is the better choice.

When the enterprise platform is the right answer

Be honest about this. If you need ratings, analyst research, global coverage including funds that publish almost nothing, point-in-time databases for backtesting, or a vendor relationship your compliance team already knows, an enterprise platform is the right tool and the contract is the price of that breadth. The same goes for institutions whose users already sit in front of a terminal. An ISIN-first API does not replace those; it replaces the part of the workflow where a developer wants the factsheet of a fund as JSON, today, with a key they created themselves.

When a market-data API is the right answer

If the product is a chart of an ETF's price, or an alert on a price level, a market-data API is the natural fit and a fund data API is the wrong tool: there is no market price in a factsheet. Many products end up using both, one for the price line and one for the fees, holdings and risk blocks, keyed by ISIN on one side and by ticker and exchange on the other.

What an ISIN-first API looks like in practice

The shape is one request per share class, one JSON document out:

typescript
const res = await fetch("https://fundfactsapi.com/api/v1/funds/IE00B4L5Y983", {
  headers: { Authorization: "Bearer ffk_live_..." },
  signal: AbortSignal.timeout(300_000), // first-ever load of a fund can take one to three minutes
});
const { name, cached, data } = await res.json();
​
console.log(name, cached);                         // "iShares Core MSCI World UCITS ETF USD (Acc)", true
console.log(data.headlineMetrics.ter);             // "0.20%"
console.log(data.riskRating, data.profile.category); // 6, "Global Blend Equity"
console.log(data.topHoldings.length, data.sector[0]); // holdings count, { label, weight }
console.log(data.annualisedReturns);               // [{ label: "1 Year", fund, index }, …]
console.log(data.dataAsOf);                        // date the figures refer to

Around that single call sit the batch endpoint (POST /api/v1/funds), name search, portfolio look-through, holdings overlap, a change feed and NDJSON export on Scale, a document extraction endpoint for funds outside the covered issuers, and an MCP server so AI assistants use the same data. Every figure is read from the fund's own published documents (product page, factsheet, KID, holdings and NAV files), which is also the provenance answer when a compliance reviewer asks where a number came from.

The limits are equally concrete: coverage is bounded by the issuers the pipeline knows (check the coverage page before committing), there is no market price, the first load of an unknown fund takes minutes rather than milliseconds, and the derived profile labels are rule-based rather than analyst-assigned. If those are acceptable, the pricing is self-serve and a free key is enough to test coverage on your own fund list before paying anything.

A decision checklist

1. Do you need prices or factsheet content? Prices: market-data API. Content: continue.
2. Do you need ratings, research or funds outside the mainstream European and US issuers? Yes: enterprise platform.
3. Is your fund list mostly UCITS ETFs and funds from the major issuers, identified by ISIN? Yes: test an ISIN-first API against your list.
4. Do you have a narrow issuer list and an engineer with time? Consider reading the documents yourself, and read the parser comparison first.
5. Will end users see the data? Check redistribution terms on any option before building.