Fund share classes explained: Acc vs Dist, hedged, retail vs institutional, clean vs bundled

Search any fund selector for "MSCI World" and you get a wall of near-identical lines: USD Acc, EUR Dist, EUR Hedged Acc, Class I, Class A, 1C, 1D. They all hold the same portfolio. The differences are in the share class — the wrapper that decides how income is treated, what currency you deal in, whether currency risk is hedged, who is allowed to buy and what you pay. Each one has its own ISIN, and if your application picks the wrong one you will show the wrong price, the wrong fee and the wrong distribution history. This guide covers the main dimensions and how to choose correctly in code.

What a share class is

A fund (or a sub-fund inside an umbrella) is one pool of assets with one portfolio manager and one strategy. Share classes are slices of that pool with different terms attached. The holdings, the sector exposure and the risk of the underlying portfolio are the same for every class; the net asset value per share, the total expense ratio, the dividend policy and sometimes the currency are not. The glossary has a compact definition of share class; below are the dimensions that matter in practice.

Accumulating vs distributing

The label varies by fund house and language. "Acc", "C", "Cap" and "Thesaurierend" all mean accumulating; "Dist", "Inc", "D", "Dis" and "Ausschüttend" all mean distributing. Xtrackers uses "1C" for accumulating and "1D" for distributing, so IE00BJ0KDQ92 (Xtrackers MSCI World UCITS ETF 1C) is an accumulating class. Rather than maintain your own dictionary of suffixes, read the normalised value: FundFacts API returns keyFacts.distribution as a clean label however the fund house spells it. See accumulating vs distributing for the deeper comparison.

This dimension is not cosmetic for performance comparison. Plot the NAV of a Dist class against an Acc class of the same fund and the Dist line trails by the cumulative distributions. Compare like with like, or use total-return series.

Currency and currency-hedged classes

A share class has a dealing currency — the currency its NAV is quoted in — which need not be the fund's base currency or the currency of the holdings. A EUR-denominated class of a global equity fund still owns dollar, yen and sterling shares; the EUR label only changes the unit of account.

A hedged class goes one step further and uses forward contracts to neutralise the difference between the fund's base currency and the class currency. The suffix is usually "Hedged", "H" or the currency plus "H" ("EUR H"). Hedged classes carry slightly higher costs and their returns diverge materially from unhedged classes when exchange rates move. They are a separate line in every sense and always have a separate ISIN.

In the API, keyFacts.currency gives the dealing currency and shareClass gives the class name as published, which is where the hedging designation appears.

Retail vs institutional

Letters like A, B, C, D, I, X, Z are the most confusing part, because the conventions differ by fund house. There is no standard.

The letter tells you almost nothing without the fund house's own definition table, which lives in the prospectus. Do not infer "retail" or "institutional" from the letter; read the minimum investment and the ongoing charge from the documents, and keep the raw class name (shareClass) so a human can check. Carmignac Patrimoine A EUR Acc (FR0010135103) illustrates the point: "A" is a Carmignac convention, "EUR" is the dealing currency and "Acc" is the distribution policy, and only the last two carry over to other managers' naming schemes.

Clean vs bundled classes

A bundled share class has a higher annual charge that includes a payment (retrocession or trail commission) passed back to the distributor or adviser who sold the fund. A clean class strips that out and charges only what the manager needs to run the fund; the adviser bills the client directly instead. The UK's Retail Distribution Review and the EU's MiFID II inducement rules pushed most distribution towards clean classes, which is why the same fund often has two retail classes a few tenths of a percent apart in TER.

For a comparison tool, a like-for-like TER comparison across fund houses only makes sense between clean classes; otherwise the difference is about distribution economics, not fund efficiency. TER and ongoing charges covers what is inside the number.

Why every class has its own ISIN

An ISIN identifies a security, and each share class is a distinct security with its own NAV, its own dealing terms and its own register. So every class gets its own ISIN; the fund as a whole does not have one. This is inconvenient when a user thinks in fund names, but it is what makes fund data unambiguous: IE00B4L5Y983 is exactly one accumulating, USD, unhedged class of one ETF, and the ISIN guide explains how the code is built.

Picking the right ISIN when users search by name

Users type "Vanguard All-World" and expect one answer. Your job is to pick the class that fits them, or to ask. A practical resolution order:

1. Currency. Prefer the class whose keyFacts.currency matches the user's reporting currency, otherwise the fund's base currency.
2. Hedging. Default to unhedged unless the user has asked for hedged exposure.
3. Distribution. Follow the user's preference if known; otherwise pick accumulating for long-horizon tools and distributing for income tools.
4. Investor type. Prefer a class the user can actually buy. For a retail app that means excluding institutional and fee-billed-separately classes.
5. Liquidity and age. Among what remains, prefer the class with the larger keyFacts.aum and the earlier keyFacts.inception, which usually has the longest price history.

Once your candidate list is a set of ISINs, the API gives you the fields to rank them:

typescript
type Prefs = { currency: string; distribution: "Accumulating" | "Distributing"; hedged: boolean };
​
async function loadFund(isin: string) {
  const res = await fetch(`https://fundfactsapi.com/api/v1/funds/${isin}`, {
    headers: { Authorization: `Bearer ${process.env.FUNDFACTS_API_KEY}` },
  });
  if (!res.ok) throw new Error(`${isin}: ${res.status}`);
  return res.json();
}
​
export async function pickShareClass(candidates: string[], prefs: Prefs) {
  const funds = await Promise.all(candidates.map(loadFund));
​
  const score = (f: any) => {
    const d = f.data;
    const isHedged = /hedged|\bH\b/i.test(d.shareClass ?? "");
    let s = 0;
    if (d.keyFacts?.currency === prefs.currency) s += 4;
    if (d.keyFacts?.distribution === prefs.distribution) s += 3;
    if (isHedged === prefs.hedged) s += 2;
    s += Math.log10((d.keyFacts?.aum ?? 1) + 1) / 10; // tie-break on size
    return s;
  };
​
  return funds.sort((a, b) => score(b) - score(a))[0];
}

The candidate ISINs come from your own product list; the API does the reading and returns the normalised fields. A cold ISIN can take one to three minutes to load the first time, so when you add a new fund family, load all of its classes once and let the 24-hour cache serve users from then on.

What stays the same across classes, and what does not

If you cache holdings at fund level to save requests, this table tells you which fields are safe to share and which must be fetched per ISIN. For the full response layout, see how to get fund data from an ISIN, or create a free key and compare two classes of the same fund yourself.