FundFacts API vs building your own factsheet and KID parser

At a glance

What the pipeline has to do

1. Find the documents. Product pages are keyed by ISIN on some sites, by internal fund IDs on others. Many sit behind an investor-type disclaimer that must be accepted before the page loads.
2. Read several formats. Factsheets are PDFs whose tables are laid out visually, not semantically. Holdings arrive as XLSX or CSV with issuer-specific column names. Some issuers expose JSON product data; most do not document it.
3. Normalise. "USD 105.4 bn", "105,400 M USD" and "$105.4B" are the same number. "Acc", "C", "1C", "Thesaurierend" and "Capitalisation" are the same distribution policy. Sector schemes differ by index provider.
4. Detect drift. A factsheet redesign does not throw an error; it returns a plausible wrong number. You need fixtures per issuer and a completeness score per field to notice.
5. Schedule and store. Monthly factsheets, daily holdings, daily NAVs: each has its own cadence and as-of semantics.

When building is right

• You need fields no API offers (for example a bespoke ESG metric only one issuer publishes).
• You cover a handful of funds from one issuer and the layout is stable.
• Data engineering is your product, not a means to it.

When buying is right

If the fund data is an input to a screener, a report, a CRM or an assistant, every hour spent on parsers is an hour not spent on the product. FundFacts API already runs the pipeline for the fund houses listed here, scores completeness per section and delivers one shape:

json
{
  "isin": "IE00B4L5Y983",
  "data": {
    "keyFacts": { "aum": "USD 105.4 bn", "distribution": "Accumulating" },
    "headlineMetrics": { "ter": 0.2 },
    "riskRating": 6,
    "topHoldings": [{ "name": "Example Corp", "weight": 4.9 }]
  }
}

(Example values.) The factsheet automation guide walks through the reporting side.