↑ Top

Management SummaryA two-minute orientation for fund professionals

---

The European fund industry moves more money than any other financial sector in the region, yet it spends an outsized share of its operating budget simply moving information about that money from one system to another. Every asset manager, every administrator, every depositary, every distributor, every regulator consumes overlapping views of the same underlying facts — net asset values, holdings, costs, risks, sustainability disclosures — and for most of the industry's history, almost every pair of counterparties has invented its own way of exchanging them.

This book is about the European answer to that problem: FundsXML.

Why a standard is needed

A mid-sized UCITS distributed across ten European countries will today feed dozens of downstream systems — fund accounting, portfolio management, depositary oversight, data vendors, regulatory portals, distributor databases, ESG analytics — each expecting fund data in its own preferred format. The information is essentially identical; the packaging is not. One counterparty wants a bespoke CSV with forty columns; another insists on an Excel workbook; a third accepts only SWIFT messages; a fourth has built a proprietary XML dialect. The operations team is therefore obliged to maintain tens of bilateral interfaces to ship the same data in different shapes, and every small change at the source — a new ISIN, a reclassified cost component, a renamed benchmark — triggers work across every one of them.

Add to this the rising tide of regulatory templates — PRIIPs KIDs, EMT, EPT, EET, EFT, TPT, AIFMD Annex IV, MMF, and ESAP submissions — and the data-exchange problem becomes not a technical inconvenience but a material component of the industry's cost base. Standardisation, once a voluntary ambition, has become a commercial and regulatory necessity.

What FundsXML is

FundsXML is an open, XML-based data standard for the exchange of fund-related information across the European asset-management industry. Governed by a non-profit initiative and continuously developed since 2001, its current version — 4.2.x — covers the full spectrum of fund data that practitioners exchange every day:

• ControlData — who sent what, when, and with which operational intent;
• Fund structure — funds, sub-funds, and share classes, with their identifiers, descriptions, classifications, and fee structures;
• Portfolio — positions across all asset classes, linked to centralised asset master data;
• Transactions and orders — subscriptions, redemptions, switches, distributions, and corporate actions;
• Regulatory modules — the FinDatEx templates (EMT, EPT, EET, EFT, TPT) embedded natively in the schema;
• Documents, signatures, and proprietary extensions — factsheets, XMLDSig signatures, and CustomDataFields.

The standard is defined by a single XML Schema Definition (XSD), validated by open tools, and supported by a growing ecosystem of converters, libraries, and worked examples. FundsXML does not attempt to replace ISO 20022, SWIFT, FIX, or openfunds; it sits alongside them, focused on the fund-data payload that those transport standards were never designed to model in detail.

Who benefits

FundsXML is used in production by asset managers, fund administrators, depositaries, distributors, data vendors, and regulators across the European market, with particularly strong adoption in the German-speaking countries and in the Luxembourg and Irish cross-border fund centres. A mid-sized administrator that adopts FundsXML typically collapses several bilateral feeds into a single canonical delivery; an asset manager that accepts FundsXML as an input format reduces its onboarding time for new distributors from weeks to days; a regulator that consumes FundsXML receives the same data that the industry already produces internally, rather than requiring a parallel reporting chain.

The economic case is straightforward: one format, one validation, one change process, many consumers.

What this book delivers

The book is organised in four parts. Part I — Foundations sets out the data problem, the underlying XML and XSD technology, and the history and architecture of FundsXML. Part II — FundsXML in Detail examines each area of the schema — ControlData, Funds, Portfolio, Transactions, Regulatory Modules, and Advanced Areas — with complete, schema-valid worked examples. Part III — Implementation and Practice covers validation, tooling, system integration, and the end-to-end delivery of a FundsXML project. Part IV — Outlook and Reference looks ahead to FundsXML in an API-driven, AI-assisted world.

A fictional Luxembourg-domiciled UCITS — the Europa Growth Fund — runs through every chapter as a continuous narrative thread, so that abstract schema constructs are always illustrated against a concrete, realistic case.

Readers with operational or managerial responsibilities may read Parts I and III and dip into Part II as required. Readers implementing FundsXML — whether on the generating or the consuming side — will find Parts II and III the working core of the book. Readers new to XML itself should begin with Chapter 2 before moving on.

↑ Top

Challenges in Fund Data ExchangeWhy the industry needs a standard

---

1.1 Setting the Scene: A Month-End at the Europa Growth Fund

It is the last business day of the month. At the fictional — but entirely representative — Europa Growth Fund, a mid-sized UCITS equity fund domiciled in Luxembourg and distributed across eleven European countries, the monthly reporting cycle has just begun.

By 7:00 a.m. CET, the fund accounting system at the administrator has produced a provisional Net Asset Value. By 9:30 a.m., the portfolio management system at the asset manager has reconciled its shadow NAV against the official one. By 10:00 a.m., twenty-three downstream systems — ranging from the depositary's oversight platform to a data vendor's classification engine, from three regulators' reporting portals to eleven distributors' fact-sheet databases — expect a fresh delivery of fund data in their preferred format.

The operations team at the Europa Growth Fund knows this moment well. One distributor wants a proprietary CSV file with forty-seven columns in a specific German locale. Another insists on an Excel workbook with macros. A third accepts only a SWIFT MT535 message for holdings. A fourth has recently migrated to an in-house XML schema that — despite its name — bears little resemblance to any public standard. The German regulator needs a PRIIPs KID, the French regulator a DICI, the Austrian distributor an EMT file, and the Italian insurer a Tripartite Template for Solvency II. The ESG team in Paris is meanwhile waiting for an EET so that Article 8 disclosures can be updated on the fund's website by noon.

Every one of these deliveries contains, at its heart, the same underlying data: one fund, three share classes, one portfolio, one NAV, one set of costs, one set of risks. Yet the operations team maintains more than thirty bilateral interfaces to ship this same information into thirty different shapes. When a single field changes — a new ISIN is added, a benchmark is renamed, a cost component is reclassified — thirty mappings must be touched, thirty test cycles must be run, thirty sign-offs must be collected.

This chapter is about why that reality exists, what it costs, and what the fund industry has been trying to do about it. It is the motivational chapter of this book. No XML syntax appears in these pages; the technology begins in Chapter 2. Here, we build the case for a standard — and, ultimately, for FundsXML — by looking honestly at the data landscape that fund professionals navigate every day.

By the end of the chapter, you should be able to:

• describe the four principal categories of data that flow through the European fund industry;
• name the main actors in a typical fund data network and the flows that connect them;
• identify the recurring problems that emerge when these flows are handled without a common standard;
• place the most important competing and complementary standards — FIX, SWIFT, ISO 20022, openfunds, and FundsXML — on a single conceptual map;
• explain why regulatory pressure, rather than voluntary coordination, has become the dominant driver of standardisation in this decade.

---

1.2 The European Fund Industry in Numbers

To appreciate the data problem, it helps to appreciate the scale of the industry that produces it.

At the time of writing, European investment funds manage assets of roughly twenty trillion euros, split approximately two-thirds into UCITS (retail-oriented, passportable across the European Union) and one-third into AIFs (alternative investment funds, from hedge funds and private equity to real estate and infrastructure vehicles). Europe hosts more than sixty thousand individual funds and sub-funds; if one counts share classes separately, the figure comfortably exceeds two hundred thousand distinct investable units, each with its own ISIN.

Luxembourg and Ireland together domicile the majority of cross-border UCITS. France, Germany, the United Kingdom, Switzerland, and the Netherlands host large domestic markets in addition. Cross-border distribution — a UCITS sold in a country other than its country of domicile — is the norm rather than the exception, and each new distribution country typically adds its own reporting quirks.

The numerical profile of daily data traffic is sobering:

• Each open-ended fund produces at least one NAV per business day; many produce several (for different valuation points, currencies, or hedged share classes). That alone yields hundreds of thousands of NAV data points per day across Europe.
• Portfolio snapshots are typically reported monthly to the public and daily internally; a mid-sized equity fund holds 80 to 150 positions, while a global multi-asset fund may hold several thousand.
• Transactions — subscriptions, redemptions, switches, distributions, corporate actions — flow continuously throughout the trading day.
• Regulatory deliveries (EMT, EPT, EET, TPT, AIFMD Annex IV, MMF, PRIIPs) vary from monthly to quarterly to ad-hoc, with the direction of travel firmly towards higher frequency and broader scope.

Behind these numbers sits a simple observation: the European fund industry has become an information-processing industry. The cost of producing, distributing, reconciling, and reporting fund data is no longer a rounding error in the total expense ratio — it is a material component of the operating cost base of every asset manager, every administrator, every distributor, and every regulator. Standardisation is therefore not a purely technical concern; it is an industrial-economics concern.

The remainder of this chapter unpacks that observation in four steps. First, we classify the data itself. Second, we identify the actors that exchange it. Third, we examine what goes wrong when that exchange happens without a shared standard. Fourth, we survey the standards that have emerged in response — culminating in the positioning of FundsXML within that landscape.

---

1.3 What Flows? A Taxonomy of Fund Data

Fund data can be organised along many dimensions: by lifecycle (static versus dynamic), by sensitivity (public versus confidential), by origin (produced internally versus sourced externally). For the purposes of this book, we adopt a pragmatic four-part taxonomy that mirrors how FundsXML itself is structured and how most practitioners think about their day-to-day work:

1. Master data — the relatively stable descriptive information about funds, share classes, and instruments;
2. Price data — NAVs, market prices, and the time series built from them;
3. Portfolio data — what a fund actually holds at a given valuation point;
4. Transaction data — the events that change holdings and capital.

Each category has its own frequency, its own sources, its own consumers, and its own pathologies. We look at them in turn, with the Europa Growth Fund as a running example.

1.3.1 Master Data

Master data is the "identity layer" of the fund industry. It answers the questions what is this fund, what is this share class, what is this instrument. Typical master-data elements include:

• Fund-level: legal name, marketing name, LEI, inception date, fund type (UCITS, AIF, ETF), domicile, regulator, fund manager, administrator, depositary, auditor, fiscal year-end, base currency, benchmark.
• Share-class-level: ISIN, WKN, Valor, local identifiers, distribution policy (accumulating vs. distributing), currency, hedging, minimum investment, management fee, performance fee, TER, launch date, share-class-specific benchmark.
• Instrument-level: ISIN, CFI, issuer LEI, maturity, coupon, sector classification, country of risk, rating.

For the Europa Growth Fund, the master data fits on a handful of pages. Yet those pages are the most-consulted and most-duplicated information in the entire system landscape. Every downstream consumer — from a fact-sheet engine to a distribution platform to a ratings provider — needs a copy. Every consumer holds that copy in its own schema, subject to its own update cadence.

Master data changes rarely — perhaps a few dozen events per year for a typical fund. But when it does change, the ripple effects are enormous: a renamed benchmark, a new share class, a fee reduction, a change of depositary. Each such event must be propagated to every downstream copy, and each missed update is a latent reconciliation break.

The characteristic failure mode of master data is silent divergence: two systems hold "the same" fund under two slightly different names, two slightly different fee structures, two slightly different inception dates — and nobody notices until an auditor or a regulator asks a question that depends on precisely the field that has drifted.

1.3.2 Price Data

Price data is the most visible output of a fund. The NAV per share is the number investors see on their statements, the number published on websites, the number used to calculate performance fees, the number that drives subscription and redemption proceeds. For a daily-priced UCITS, the NAV is produced every business day after market close, validated overnight, and released the next morning.

Price data has several subtypes:

• Official NAV — the one used for subscriptions and redemptions; produced by the administrator, validated by the asset manager and depositary.
• Indicative / intra-day NAV — for ETFs, published throughout the trading day.
• Shadow NAV — the asset manager's own calculation for internal reconciliation.
• Historical NAV time series — used for performance calculations, risk indicators, and back-testing.
• Dividend and distribution amounts — technically an event rather than a price, but usually delivered together.
• Performance indicators — cumulative and annualised returns, ratios such as Sharpe and Sortino, volatility, tracking error.

Compared with master data, price data is high-volume and highly time-sensitive. A delayed NAV delays every downstream process that depends on it, from the publication of daily prices on Morningstar to the valuation of a feeder fund that holds the Europa Growth Fund as a position.

The characteristic failure mode of price data is format fragmentation. The NAV itself is a single decimal number, but the way it travels differs: one distributor takes a CSV file named NAV_YYYYMMDD.csv, another a SWIFT MT535 with an embedded price block, another a proprietary JSON endpoint, another an emailed Excel sheet. Multiply by share classes and currencies and the number of outbound NAV feeds for a mid-sized fund house easily exceeds one hundred per day.

1.3.3 Portfolio Data

Portfolio data describes, at a specific valuation point, everything a fund holds: securities, cash, derivatives, other funds, real assets, receivables, and payables. A single portfolio snapshot for the Europa Growth Fund might contain:

• one hundred and twenty equity positions in twenty-two countries;
• a basket of fifteen futures used to equitise cash;
• cash balances in five currencies;
• three FX forwards hedging the share-class-currency exposure;
• accrued dividends, pending trades, and management-fee accruals.

Each position has its own descriptive fields — identifier, description, quantity, price, market value, weight, currency, country of risk, sector, credit rating, maturity — and each consumer of the portfolio has its own requirements about which of those fields must be present, in what precision, and in which reference currency.

Portfolio data feeds:

• risk systems, which compute exposures, VaR, stress tests, and counterparty concentrations;
• performance-attribution systems, which decompose returns into allocation and selection effects;
• compliance systems, which check UCITS eligibility, concentration limits, and ESG exclusions;
• regulatory reporting, from AIFMD Annex IV to Solvency II look-through to PRIIPs risk calculations;
• transparency reporting, such as monthly top-ten holdings or full portfolio disclosures.

The characteristic failure mode of portfolio data is semantic ambiguity. The phrase "market value" has half a dozen legitimate interpretations (clean vs. dirty price for bonds, pre- vs. post-accrual, including vs. excluding cash). The phrase "country" may mean country of incorporation, country of tax residence, country of risk, or country of the primary listing. Without a shared glossary — and without a schema that forces the producer to declare which variant is intended — each consumer is free to guess, and guesses diverge.

1.3.4 Transaction Data

Transactions are the events that change a fund's holdings or its capital base. They come in two broad flavours:

• Capital transactions — subscriptions, redemptions, switches between share classes, distributions to investors;
• Investment transactions — buys, sells, coupon receipts, dividend receipts, corporate actions, collateral movements, FX trades.

Each transaction has a richer event-like structure than a static position: it has a trade date, a value date, a settlement date, a counterparty, a price, a commission, a tax, and — crucially — a state (pending, matched, settled, failed, cancelled). Over the life of a single order, multiple transaction records may be produced as the state evolves.

For the Europa Growth Fund, transaction data flows in two directions. Outbound transactions leave the portfolio management system for the administrator, the depositary, the brokers, and the clearing system. Inbound transactions arrive from the transfer agent (as share-class subscriptions and redemptions), from the custodian (as settlement confirmations), and from data vendors (as corporate-action notifications).

The characteristic failure mode of transaction data is mismatched state: two systems agree that a trade happened, but disagree about whether it is settled, whether the tax was withheld, or whether a corporate action has been applied. Reconciliation teams at asset managers spend a significant portion of their working day chasing exactly these mismatches.

1.3.5 A Consolidated View

Table 1.1 summarises the four categories along the dimensions most relevant for data-exchange design.

Table 1.1 — The four categories of fund data

Category	Typical frequency	Primary producer	Primary consumers	Dominant pain point
Master data	Rare events (days/weeks)	Asset manager / administrator	Distributors, vendors, regulators, website	Silent divergence between copies
Price data	Daily (intra-day for ETFs)	Administrator	Distributors, vendors, platforms, investors	Format fragmentation per channel
Portfolio data	Daily internal / monthly public	Administrator / portfolio manager	Risk, compliance, regulators, transparency feeds	Semantic ambiguity of fields
Transaction data	Continuous (event-driven)	Portfolio manager, transfer agent, custodian	Reconciliation, accounting, regulators	Mismatched state across systems

The insight to carry forward is that a single standard must accommodate all four categories if it is to meaningfully reduce the bilateral-mapping problem. A standard that covers only master data leaves the NAV and portfolio flows untouched; a standard that covers only transactions does nothing for the fact-sheet engine. The ambition of FundsXML — as we will see in Chapter 3 — is precisely to provide a single model that can express all four.

---

1.4 Who Exchanges Data with Whom? The Actors and Their Flows

If the data taxonomy is the what, the actor landscape is the who. A realistic picture of that landscape is the first step towards understanding why bilateral mappings multiply so quickly.

1.4.1 The Principal Actors

Around any European investment fund, one finds — at a minimum — the following roles:

• The asset manager (management company, KVG, ManCo) is the legal entity responsible for managing the fund. It makes investment decisions, maintains the investment strategy, and bears ultimate responsibility for the product.
• The fund administrator performs fund accounting, calculates the NAV, maintains the shareholder register (unless the transfer agent is a separate entity), and produces financial statements. In Luxembourg and Ireland, fund administration is typically outsourced to large specialised banks.
• The depositary (custodian bank) holds the fund's assets in safekeeping, monitors cash flows, and performs oversight duties mandated by UCITS and AIFMD.
• The transfer agent processes subscriptions, redemptions, and share-class switches on behalf of investors; it maintains the register of holders.
• Distributors — retail banks, private banks, independent financial advisers, online platforms, insurance companies, pension schemes — bring the fund to end investors. Each distributor has its own onboarding process, its own data requirements, and its own delivery preferences.
• Data vendors and aggregators — Bloomberg, Refinitiv, Morningstar, WM Datenservice, FundConnect, Kneip, MountainView, and many others — collect fund data from producers and redistribute it, in normalised form, to subscribers across the financial industry.
• Regulators — national authorities such as BaFin (Germany), AMF (France), CSSF (Luxembourg), Central Bank of Ireland, FMA (Austria), FINMA (Switzerland), as well as the European Securities and Markets Authority (ESMA) — require regular reporting under UCITS, AIFMD, MiFID II, PRIIPs, SFDR, and other regimes.
• Auditors review the fund's financial statements and regulatory disclosures annually.
• Internal stakeholders — the portfolio managers themselves, risk, compliance, product, legal, marketing, and client reporting teams — consume fund data for purposes ranging from daily decision-making to glossy brochures.

1.4.2 A Representative Flow Diagram

Figure 1.1 sketches the data-flow network of the Europa Growth Fund. The fund sits at the centre; around it are the actors just listed; between them run the arrows that represent data flows.

Figure 1.1 — Data flows around the Europa Growth Fund

(A full-page diagram placed here in the final book. The diagram shows the Europa Growth Fund at the centre, surrounded by the asset manager, administrator, depositary, transfer agent, distributors, data vendors, regulators, and internal consumers. Arrows are colour-coded by data category — master, price, portfolio, transaction — and labelled with typical frequencies.)

Even for a single mid-sized fund, the diagram has more than twenty arrows. For a fund house running a hundred funds, the number of bilateral flows runs into the thousands. It is this combinatorial explosion — not the volume of any single flow — that makes unstandardised data exchange so expensive.

1.4.3 Three End-to-End Flows in Detail

To make the picture concrete, consider three complete flows that together account for much of the daily traffic around the Europa Growth Fund.

Flow 1 — Daily NAV publication. At 18:00 CET, the administrator's fund-accounting system strikes the books. By 22:00, after overnight pricing feeds have been applied and the depositary has performed its cash-monitoring checks, a draft NAV is available. By 07:00 the next morning, the asset manager's oversight team reviews the NAV against its shadow calculation. On release, the NAV must be delivered to: the asset manager's website, the administrator's own transparency portal, Bloomberg, Refinitiv, Morningstar, three regional data vendors, eleven distributors, and two fund-of-funds that hold the Europa Growth Fund as a position. Each of these recipients expects the NAV in its preferred format.

Flow 2 — PRIIPs KID generation and distribution. Every twelve months, and whenever market conditions materially change, a Key Information Document must be produced for each share class of the Europa Growth Fund. The KID contains risk indicators, cost disclosures, and performance scenarios — all of which depend on portfolio data, price history, and cost data. Once generated, the KID PDF must be pushed to every distributor in every country where the fund is sold, in the local language, with version tracking that allows investors to retrieve the exact KID in effect on the day they subscribed. The data feeding the KID is the same data feeding half a dozen other reports; the delivery mechanism is entirely different.

Flow 3 — MiFID II cost and target-market reporting. Under MiFID II, distributors must receive, for every share class they sell, a European MiFID Template (EMT) detailing target market, costs, and charges. The EMT is refreshed monthly or quarterly and whenever the underlying data changes. It is distributed via a mix of FinDatEx channels, data-vendor repositories, and direct bilateral feeds. For a fund sold in eleven countries through a hundred distributors, dozens of EMT deliveries per month are not unusual.

The point of walking through these three flows is to emphasise that the same underlying dataset feeds very different outbound products — and that the effort of producing those outbound products, in the absence of a standard, scales linearly with the number of downstream formats rather than with the complexity of the data itself.

---

1.5 What Goes Wrong Without a Standard

Having mapped the data and the actors, we now turn to the recurring pathologies that afflict unstandardised data exchange. Each of the six pathologies below is common enough that every experienced fund-operations professional will recognise it. For each, we offer a short description, a concrete illustration from the Europa Growth Fund, and a sense of the cost it imposes.

1.5.1 Proprietary Formats and the n² Interface Problem

The most immediate symptom of missing standardisation is the proliferation of bilateral, proprietary formats. When n parties need to exchange data and no shared format exists, the number of distinct mappings required scales as n × (n − 1), i.e. roughly as the square of the number of participants. A network of ten counterparties requires ninety mappings; one hundred counterparties, roughly ten thousand.

At the Europa Growth Fund, the outbound NAV feed illustrates the problem in miniature. Thirteen distributors receive the daily NAV:

• four accept a CSV with semicolon separators and German decimal comma;
• three accept the same CSV with comma separators and English decimal point;
• two require an Excel workbook with a specific sheet name;
• two use a proprietary XML dialect inherited from a legacy project;
• one consumes a SWIFT MT535;
• one ingests a REST endpoint exposing JSON.

None of these formats is inherently wrong. Each was rational at the time it was chosen. But collectively, they mean that a change to the NAV payload — for example, adding a hedged-currency NAV for a new share class — triggers thirteen distinct change requests, thirteen distinct test cycles, and thirteen distinct go-live windows. The marginal cost of adding the fourteenth distributor is not the cost of understanding one more format; it is the cost of adding yet another line to an already-sprawling maintenance matrix.

A shared standard collapses n × (n − 1) into something closer to n: each participant implements the standard once, and bilateral mappings disappear. This is the single most important economic argument for standardisation — and it is, in microcosm, the argument for FundsXML.

1.5.2 Identifier Confusion

A fund or instrument rarely has just one identifier. It may have an ISIN (international), a WKN (German market), a Valor (Swiss market), a SEDOL (UK market), a Bloomberg ticker, a RIC (Refinitiv Instrument Code), a CUSIP (for North-American assets), an in-house code, and a legacy identifier inherited from a pre-merger system. Each system in the chain privileges one of these identifiers as primary and treats the others as aliases — if it tracks them at all.

At the Europa Growth Fund, a recurring incident pattern involves corporate actions on small-cap holdings. The custodian reports the event using the ISIN of the new security; the portfolio management system stores positions under WKN; the risk system uses an in-house code that maps to the pre-event ISIN. For three days after the event, reports from the three systems disagree, and the reconciliation team must manually trace the event through each identifier.

A common standard does not, by itself, eliminate the existence of multiple identifiers — the world has many identifiers for good reasons. But a standard can specify how multiple identifiers are carried together on the same record, and which is authoritative, so that the consumer need not guess. FundsXML makes this explicit through its Identifiers and OtherIDs structures, as we will see in Chapter 5.

1.5.3 Semantic Inconsistency

Two systems may use the same field name for subtly different concepts. A few examples:

• NAV may mean the official NAV, the indicative NAV, the gross NAV (before the performance fee crystallisation), the net NAV (after all fees), the pre-swing NAV, or the post-swing NAV.
• Total Expense Ratio may be calculated on an ex-ante basis or an ex-post basis, may include or exclude performance fees, may include or exclude transaction costs.
• Country may mean country of domicile, country of incorporation, country of risk, country of tax residence, country of the primary listing, or country of the underlying exposure.
• Exposure may be gross, net, commitment-based, or VaR-based.

At the Europa Growth Fund, an illustrative case involves the ESG team's monthly report. The team reports carbon intensity using country of risk; the marketing team's fact-sheet engine reports country allocation using country of incorporation; a third-party research provider uses country of listing. All three numbers end up on the fund's website, and none of them matches. An internal audit eventually determines that all three are technically correct — they just answer different questions. But investors and sales staff, unaware of the distinction, spend weeks trying to reconcile what cannot be reconciled.

A standard addresses semantic inconsistency through two mechanisms: a typed schema that constrains what a field can contain, and a shared glossary that defines what each field means. FundsXML provides both, and the habit of consulting the schema definition before using a field is perhaps the most important discipline a fund-data practitioner can acquire.

1.5.4 Versioning and Release Chaos

Every format evolves. A new regulatory requirement adds a field; a deprecated field is removed; a type is tightened; an enumeration gains new values. In an unstandardised environment, each bilateral format evolves independently, on its own schedule, with its own change-notification mechanism — if any.

At the Europa Growth Fund, the operations team has a wall-chart that tracks the effective version of each outbound format by counterparty. The chart has over sixty rows. When a counterparty announces a format change, the team must plan a migration window, produce parallel outputs during the transition, and coordinate cut-over with the receiver — all while maintaining the other fifty-nine flows unchanged. Mistakes manifest as delivery failures at precisely the moment no one can afford them: the month-end cycle.

A shared standard does not eliminate versioning — FundsXML itself has evolved from 1.0 to 4.2.x over more than two decades — but it concentrates the versioning discussion into a single conversation that all participants can follow, rather than hundreds of bilateral negotiations.

1.5.5 Manual Work and Operational Risk

The preceding four pathologies all share a common consequence: they move work from machines, which are cheap, to humans, who are expensive, slow, and error-prone. Every field that cannot be parsed automatically must be read by someone. Every reconciliation break must be investigated by someone. Every format migration must be project-managed by someone.

Industry benchmarks vary, but it is not unusual for a mid-sized fund house to estimate the fully-loaded cost of a single bilateral feed interface at tens of thousands of euros per year for maintenance alone, exclusive of the original build cost. For a fund house with five hundred active interfaces, the annual cost of not being standardised runs into the millions. This cost is invisible on any single balance sheet line, because it is spread across operations, IT, change management, and vendor contracts — but it is very real, and it is ultimately borne by the end investor in the form of management fees.

Beyond cost, there is risk. Every manual touch is an opportunity for error. Every reconciliation break, if missed, can turn into a pricing error, a regulatory finding, or a reputational incident. The fund industry has learned, through painful experience, that operational risk is not a separate category of risk; it is a first-class risk that can easily exceed market risk for some activities.

1.5.6 The Hidden Cost of Non-Standardisation

Pulling the five pathologies together yields a simple conclusion: the cost of not standardising is not zero, and it is not constant. It grows non-linearly with the number of participants, the number of formats, and the pace of regulatory change. For decades, the industry tolerated this cost because each individual participant perceived its own share as manageable. In the past decade, three things have changed:

• Regulation has multiplied the number of outbound data products (see Section 1.6), shifting the cost curve sharply upward.
• Cross-border distribution has multiplied the number of bilateral endpoints per fund.
• Data-driven products — robo-advisers, ETF platforms, ESG-labelled mandates — have created new consumers with new requirements, accelerating format proliferation.

Standardisation, in other words, used to be a nice-to-have. It is now an economic necessity. The question is no longer whether to standardise, but which standard, applied to which part of the flow. The rest of this chapter turns to that question.

---

1.6 Regulation as the Dominant Driver

If one had to pick a single reason why FundsXML — and standardisation in general — has moved from the periphery to the centre of fund operations in the past decade, it would be regulation. Voluntary industry coordination, historically, has been slow; regulatory deadlines have not.

1.6.1 The Regulatory Stack at a Glance

European fund regulation is dense. The list below is not exhaustive, but it covers the regulations that most directly drive data-exchange requirements:

• UCITS (Undertakings for Collective Investment in Transferable Securities) — the foundation of European retail fund regulation, mandating investment restrictions, risk management, and investor disclosure. UCITS IV introduced the Key Investor Information Document (KIID); UCITS V and VI tightened depositary rules and remuneration disclosures.
• AIFMD (Alternative Investment Fund Managers Directive) — the parallel regime for AIFs, with extensive regulatory reporting through Annex IV.
• MiFID II / MiFIR (Markets in Financial Instruments Directive/Regulation) — imposes target-market, cost, and charges disclosures on distributors, driving the EMT template.
• PRIIPs (Packaged Retail and Insurance-based Investment Products Regulation) — replaces the UCITS KIID with the PRIIPs KID for retail products, driving the EPT template for the underlying calculations.
• SFDR (Sustainable Finance Disclosure Regulation) and the EU Taxonomy Regulation — mandate sustainability-related disclosures at entity and product level, driving the EET template.
• Solvency II — requires insurance companies to look through their fund holdings to the underlying assets for capital calculations, driving the TPT template.
• Money Market Fund Regulation — specific disclosure and reporting rules for MMFs.
• DORA (Digital Operational Resilience Act) — elevates the operational-resilience expectations on all regulated financial entities, indirectly raising the bar for data-exchange quality.
• ESAP (European Single Access Point) — creates a central EU repository for public corporate and financial information, expected to become a major aggregation point for fund data in the coming years.

1.6.2 From Regulation to Data Requirement

Each of these regulations translates into concrete data requirements. Table 1.2 maps a selection of regulations onto the data categories they most directly affect and onto the FundsXML module that expresses them — a forward reference to Chapter 8, where the regulatory modules are treated in depth.

Table 1.2 — Regulation to FundsXML module

Regulation	Primary data required	FundsXML touchpoint
MiFID II (target market, costs)	Share-class master data, costs, target-market classification	EMT within RegulatoryReportings
PRIIPs KID	Risk indicator, cost table, performance scenarios, historical NAVs	EPT within RegulatoryReportings
SFDR / EU Taxonomy	ESG product classification, PAI indicators, taxonomy alignment	EET within RegulatoryReportings
Solvency II look-through	Full portfolio, issuer ratings, country of risk, durations	TPT within RegulatoryReportings
AIFMD Annex IV	Portfolio, leverage, liquidity, counterparty exposures	Portfolio + CustomDataFields
UCITS / MMFR disclosures	NAV, portfolio composition, liquidity buckets	FundDynamicData + Portfolio
ESAP	Consolidated public fund disclosures	Documents + regulatory modules

The practical consequence of this mapping is important: regulators, although they do not mandate FundsXML directly, increasingly mandate the data that FundsXML is designed to carry. The path of least resistance for most fund houses is to produce a single canonical FundsXML representation of their regulatory data and transform it into whatever filing format the regulator actually accepts. The canonical representation is what makes the regulatory workload manageable in the first place.

1.6.3 The Pace of Change

Ten years ago, a mid-sized fund house might have had one major regulatory data project per year. Today, it is rarely fewer than three concurrently: a PRIIPs refinement, an SFDR amendment, a MiFID II review, a Solvency II look-through change, a DORA implementation. The regulatory roadmap for the remainder of this decade shows no sign of slowing, and the direction of travel is unmistakable: more fields, more frequently, more comparably, more publicly.

Against that backdrop, the argument for a stable, well-governed, schema-based standard is no longer intellectual. It is operational. A fund house that enters each new regulatory project with a canonical data model already in place pays the fixed cost once; a fund house that treats each project as a bespoke initiative pays the fixed cost again and again.

---

1.7 The Standards Landscape

FundsXML is not alone. Several standards — some older, some newer, some complementary, some competing — populate the European fund data landscape. A practitioner reading this book should be able to place each of them on a mental map. This section provides that map.

1.7.1 FIX Protocol

The Financial Information eXchange (FIX) protocol was born in 1992 out of a bilateral effort between Fidelity Investments and Salomon Brothers to standardise equity-trade communications. Today, FIX is the dominant protocol for electronic order entry and trade execution in equity, derivatives, and increasingly fixed-income markets. Every sell-side trading desk speaks FIX; every order management system on the buy side speaks FIX; every execution venue exposes a FIX gateway.

FIX is a session-oriented, message-oriented protocol, optimised for low-latency, high-volume order flow. Its data model is centred on orders and executions, not on funds. It does not attempt to describe a fund's master data, its NAV, or its regulatory disclosures. It is, in the taxonomy of Section 1.3, primarily a transaction-data standard — and within transactions, primarily investment transactions rather than capital transactions.

FIX is therefore complementary to FundsXML, not competing. A fund's portfolio manager uses FIX to send orders to brokers; the resulting executions feed the portfolio that FundsXML then describes.

1.7.2 SWIFT MT and MX

SWIFT (Society for Worldwide Interbank Financial Telecommunication) operates the global messaging network that underpins interbank payments, securities settlement, trade finance, and treasury. Its legacy MT message series — MT5xx for securities — has been the backbone of cross-border custody and settlement for decades. MT535 carries statements of holdings; MT536 carries statements of transactions; MT540–MT548 carry settlement instructions and confirmations.

SWIFT is migrating its messages to MX, the XML-based successor built on ISO 20022. The migration is well underway for payments and is progressing, more slowly, for securities.

For the fund industry, SWIFT is the dominant channel between funds and their custodians and depositaries. It handles holdings statements, settlement confirmations, income events, and corporate-action notifications. Like FIX, SWIFT is complementary to FundsXML: it covers a specific segment of the flow — the custody and settlement leg — that FundsXML does not attempt to address directly. A typical operational architecture consumes SWIFT messages from the custodian, translates them into internal representations, and re-emits the resulting fund data in FundsXML for onward distribution.

1.7.3 ISO 20022

ISO 20022 is the international standard for financial-industry messaging. Unlike FIX, SWIFT MT, or FundsXML, ISO 20022 is not a single message format; it is a methodology — a metamodel and a repository of business components — from which concrete messages in many domains are derived. Payments, securities, cards, foreign exchange, trade services, and increasingly investment funds all have ISO 20022 message sets.

For investment funds, ISO 20022 defines message families such as setr (order processing), semt (statements), sese (settlement), and reda (reference data). These messages overlap in scope with FIX, SWIFT MT, and — in the master-data and price areas — with FundsXML.

The relationship between ISO 20022 and FundsXML is subtle. ISO 20022 is a broad, cross-industry, cross-domain framework governed by a formal ISO process; its governance is heavyweight and its release cycles are long. FundsXML is a focused, fund-industry-specific standard that can iterate faster and cover fund-specific concepts — regulatory templates, FinDatEx embedding, multi-lingual fact-sheet text — that an ISO 20022 message would struggle to represent natively. The two standards are best thought of as operating at different levels of abstraction: ISO 20022 dominates interbank and custody flows; FundsXML dominates fund-product-centric flows. They coexist, and well-architected systems translate between them at the boundary.

1.7.4 openfunds

openfunds is a lightweight, community-driven initiative originating in Switzerland that defines a standardised vocabulary of fund master-data fields. Rather than prescribing a message format, openfunds publishes a catalogue of approximately five hundred field definitions — each with a stable identifier, a clear definition, a type, and guidance on usage. The catalogue has been widely adopted by Swiss and German market participants for the exchange of fund reference data.

openfunds answers the semantic-inconsistency problem of Section 1.5.3 for master data: when two parties agree to use openfunds field OFST005010 for a benchmark name, they agree on what the field means. openfunds does not, however, prescribe how that field should be carried on the wire — whether as CSV, JSON, Excel, or XML — nor does it cover portfolios, transactions, or regulatory reporting.

openfunds is therefore complementary to FundsXML in theory and, in practice, has strongly influenced the master-data portions of the FundsXML schema. Many openfunds fields map directly to FundsXML elements, and a common pattern is to use openfunds identifiers as the authoritative semantic reference while using FundsXML as the transport and structural container.

1.7.5 FundsXML

FundsXML is the subject of this book. In one sentence: FundsXML is a comprehensive, schema-based XML standard for the exchange of fund-centric data — master data, price data, portfolio data, transactions, and regulatory reporting — governed by an industry initiative and maintained as an open standard.

Its defining characteristics, each of which we will revisit in depth in later chapters, are:

• Fund-centric scope. Unlike FIX (trade-centric), SWIFT (message-centric), or ISO 20022 (bank-centric), FundsXML is built around the concept of a fund and its share classes. A single FundsXML document can describe a fund's identity, its NAV, its holdings, its transactions, and its regulatory disclosures in one coherent structure.
• Schema-based validation. FundsXML is defined by an XSD schema, enabling automated validation of every incoming and outgoing document. This single property eliminates entire categories of silent errors.
• Regulatory embedding. FundsXML provides first-class support for the FinDatEx templates (EMT, EPT, EET, EFT, TPT), allowing a single delivery to carry all regulatory data a distributor needs.
• Extensibility. The CustomDataFields mechanism allows proprietary extensions without breaking schema compatibility.
• Open governance. The standard is maintained by an industry initiative with representatives from asset managers, administrators, vendors, and regulators.

1.7.6 A Comparative Map

Table 1.3 places the five standards side by side along four dimensions: scope, message type, governance model, and depth of adoption in the European fund industry.

Table 1.3 — A comparative map of fund-industry standards

Standard	Primary scope	Message type	Governance	European fund adoption
FIX	Order entry, execution	Session-based, tag/value	FIX Trading Community	Ubiquitous for trading
SWIFT MT/MX	Custody, settlement, payments	Store-and-forward messages	SWIFT cooperative	Ubiquitous for custody
ISO 20022	Cross-industry financial messaging	XML messages from a metamodel	ISO / RMG	Growing, heterogeneous
openfunds	Master-data vocabulary	Field catalogue (format-agnostic)	openfunds association	Strong in DACH region
FundsXML	Fund product data end-to-end	Schema-based XML documents	FundsXML initiative	Strong and growing, especially for regulatory flows

The map highlights that FundsXML occupies a distinct and largely uncontested niche: the end-to-end description of a fund product — its identity, its dynamics, its holdings, its regulatory disclosures — as a single validated document. The other standards are not displaced; they continue to dominate their respective niches. A realistic operational architecture uses several of them together: FIX to the brokers, SWIFT to the custodian, openfunds as a semantic reference, FundsXML as the outbound distribution and regulatory medium.

---

1.8 Positioning FundsXML

The preceding sections have built, step by step, the case for a standard that:

• covers all four categories of fund data in a single coherent model;
• addresses the combinatorial explosion of bilateral mappings;
• embeds regulatory templates as first-class citizens;
• rests on a validated schema rather than on informal agreements;
• complements, rather than competes with, the established transaction-level and custody-level standards.

FundsXML is the standard that most completely satisfies these criteria for the European fund industry today. It is not the only answer to any single question; but it is the only standard that attempts to answer all of the questions together. Its closest conceptual neighbour, ISO 20022, is broader but less fund-specific and slower to evolve. Its closest semantic neighbour, openfunds, is sharper on master-data definitions but does not prescribe a transport structure. Its closest transactional neighbours, FIX and SWIFT, do not attempt to describe a fund product at all.

Viewed in this landscape, the choice for a fund-industry practitioner is not usually FundsXML versus something else, but rather FundsXML together with the right neighbours — with FIX or equivalent at the trading interface, SWIFT or ISO 20022 at the custody interface, openfunds as a shared dictionary, and FundsXML as the canonical fund-product representation that feeds distributors, regulators, and transparency channels.

For the Europa Growth Fund, the implication is concrete. By adopting FundsXML as the canonical internal model for fund-product data, the operations team can:

• retire bilateral proprietary formats in favour of a single outbound FundsXML stream that each consumer transforms locally;
• generate all FinDatEx regulatory templates from one authoritative source, eliminating cross-template inconsistency;
• validate every outbound document against a schema before it leaves the building, catching errors at the cheapest possible point;
• negotiate format changes with counterparties through a single version conversation rather than through thirty bilateral negotiations.

None of this happens overnight, and Chapter 13 devotes itself to the project mechanics of getting from today to that future state. But the destination is worth naming now, at the start of the book, so that every subsequent chapter can be read with a clear picture of what it contributes.

---

1.9 Key Takeaways

• The European fund industry is, in economic terms, an information-processing industry; the cost of moving fund data across the ecosystem is material and growing.
• Fund data divides naturally into four categories — master data, price data, portfolio data, and transaction data — each with its own frequency, producers, consumers, and characteristic failure modes.
• A realistic flow diagram around a single fund involves more than twenty bilateral exchanges; at the level of a fund house, the number runs into the thousands and grows as the square of the number of counterparties in the absence of a standard.
• The dominant pathologies of unstandardised exchange are proprietary-format proliferation, identifier confusion, semantic inconsistency, version chaos, and operational risk — all of which translate directly into cost and, ultimately, into fees borne by the end investor.
• Regulatory pressure has transformed standardisation from a nice-to-have into an operational necessity; a canonical fund-data model is now the path of least resistance through an ever-denser regulatory stack.
• FIX, SWIFT, ISO 20022, openfunds, and FundsXML coexist on a shared landscape. FundsXML occupies the distinct and largely uncontested niche of end-to-end fund-product description, and is complementary to, rather than competing with, the transaction-level and custody-level standards.
• The rest of this book develops, in detail, how FundsXML fulfils that role — starting in Chapter 2 with the XML and XSD technology on which it rests, and proceeding in Chapter 3 to the architecture of the standard itself.

↑ Top

XML and XSD — The Technological BasisFoundational knowledge for working with FundsXML

---

2.1 From "Why" to "How": A Short Hop

Chapter 1 built the case for a single, shared standard for fund data. It did so deliberately without a single line of XML: the argument there was economic and operational, not technical. This chapter begins the technical half of the journey. It introduces XML and XSD — the two technologies on which FundsXML rests — and it does so from the perspective of a fund professional who needs to read, validate, query, and transform fund-data documents, not from the perspective of a software engineer building an XML parser from scratch.

Return, for a moment, to the Europa Growth Fund. At the end of Chapter 1, the operations team had decided — at least in principle — to adopt FundsXML as the canonical representation of its fund-product data. The next question on the team's mind is very practical: what does such a FundsXML file actually look like? When a colleague drops a 2-megabyte document on the desk and says "this is the monthly delivery", what should we expect to see? How do we confirm that the file is correct before we send it out? How do we extract the twenty fields that the fact-sheet engine needs? How do we turn the same file into the CSV that a Swiss distributor still insists on?

Those are the questions this chapter answers in general terms. Chapter 3 will then apply the answers to the specific shape of the FundsXML schema; Chapters 4 to 9 will walk through the schema module by module; Chapter 10 will explain the two-stage validation discipline that keeps production deliveries healthy. Everything from here on depends on the vocabulary of XML and XSD being second nature, and so the investment of thirty pages at this point is repaid many times over in the chapters that follow.

The chapter is deliberately practical. XML is a large specification with many corners that FundsXML does not use, and this book does not visit them. Where a topic is genuinely optional for a fund practitioner, we say so and move on. Where a topic matters every day — element-versus-attribute design, schema validation, namespaces, the basic XPath idiom — we spend the time.

By the end of this chapter, you should be able to:

• read and write well-formed XML documents and recognise the most common syntactic mistakes;
• explain the purpose of XML namespaces and interpret a namespaced document;
• read an XSD schema and map its declarations to the instance documents they constrain;
• describe the difference between well-formedness and schema validity, and between schema validation and business-rule validation;
• navigate an XML document with elementary XPath expressions;
• understand what an XSLT transformation does and follow a simple stylesheet end to end;
• name the tools a fund-industry practitioner typically uses for day-to-day XML work and know which later chapter treats each of them in depth.

No prior XML experience is assumed. Readers who already write XSLT 3.0 in their sleep may skim the first half of the chapter and rejoin us at §2.10.

---

2.2 XML in One Page

At its heart, XML is a notation for writing down trees of data as plain text. A document is a single tree with a single root. Every branch of the tree is an element. Each element has a name, may carry attributes, may contain other elements, and may contain text. That is essentially the whole data model; everything else in this chapter is either syntax that expresses this model or a schema language that constrains it.

The Europa Growth Fund, stripped to its bare essentials, looks like this in real FundsXML:

<?xml version="1.0" encoding="UTF-8"?>
<FundsXML4 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:noNamespaceSchemaLocation="FundsXML4.xsd">
  <ControlData>
    <UniqueDocumentID>EGF-20260331-001</UniqueDocumentID>
    <DocumentGenerated>2026-04-01T06:47:13Z</DocumentGenerated>
    <Version>4.2.8</Version>
    <ContentDate>2026-03-31</ContentDate>
    <DataSupplier>
      <SystemCountry>LU</SystemCountry>
      <Short>EAM</Short>
      <Name>Europa Asset Management S.A.</Name>
      <Type>IC</Type>
    </DataSupplier>
    <DataOperation>INITIAL</DataOperation>
    <Language>en</Language>
  </ControlData>
  <Funds>
    <Fund>
      <Identifiers>
        <LEI>549300ABCDEFGHIJ1234</LEI>
      </Identifiers>
      <Names>
        <OfficialName>Europa Growth Fund</OfficialName>
      </Names>
      <Currency>EUR</Currency>
      <SingleFundFlag>true</SingleFundFlag>
      <FundDynamicData>
        <TotalAssetValues>
          <TotalAssetValue>
            <NavDate>2026-03-31</NavDate>
            <TotalAssetNature>OFFICIAL</TotalAssetNature>
            <TotalNetAssetValue>
              <Amount ccy="EUR">464552848.78</Amount>
            </TotalNetAssetValue>
          </TotalAssetValue>
        </TotalAssetValues>
      </FundDynamicData>
      <SingleFund>
        <ShareClasses>
          <ShareClass>
            <Identifiers>
              <ISIN>LU1234567890</ISIN>
            </Identifiers>
            <Names>
              <OfficialName>Europa Growth Fund I EUR Acc</OfficialName>
            </Names>
            <Currency>EUR</Currency>
          </ShareClass>
          <ShareClass>
            <Identifiers>
              <ISIN>LU1234567892</ISIN>
            </Identifiers>
            <Names>
              <OfficialName>Europa Growth Fund R CHF Acc Hedged</OfficialName>
            </Names>
            <Currency>CHF</Currency>
          </ShareClass>
        </ShareClasses>
      </SingleFund>
    </Fund>
  </Funds>
</FundsXML4>

Three observations are worth making before going further. First, this is a minimal but schema-valid FundsXML document — it validates against the real FundsXML4.xsd without errors (Appendix D contains the full set of progressively richer examples). The document carries a ControlData envelope that identifies the delivery, followed by a Funds block with a single fund and its two share classes. Chapters 4 and 5 explain every element in this document in depth; for now, read it as a map of the territory ahead.

Second, the document is entirely human-readable. A fund operations analyst can inspect it with any text editor and, after a minute of orientation, understand it without tooling. The element names — ControlData, Fund, Names, OfficialName, Currency, ShareClass, ISIN — read almost like a structured form. This readability is one of XML's enduring strengths and is a large part of why regulators and industry bodies have chosen XML-based formats for durable disclosures.

Third, the tree structure is visible in the indentation but does not depend on it. XML ignores most whitespace between elements; the indentation is a convenience for humans. Parsers see the same tree regardless of how the file is formatted.

A note on the examples in this chapter. The document above and the share-class examples later in this chapter are real FundsXML validated against the 4.2.8 schema. A small number of examples in the XML-syntax and namespace sections (§2.3–§2.5) use simplified, hand-rolled elements to illustrate general XML concepts in isolation; where this is the case, the text says so. Every example that claims to be FundsXML is schema-valid.

With this much in hand, we can now be precise about the syntactic rules that make a document well-formed.

---

2.3 XML Syntax — Elements, Attributes, Text

2.3.1 Well-formedness

An XML document is well-formed if it obeys a small number of strict rules. A well-formed document can be parsed by any conforming XML processor, regardless of whether it matches any schema. The rules are:

• Exactly one root element. The outermost pair of tags encloses everything. In the Europa Growth Fund example above, <FundsXML4> is the root.
• Every start tag has a matching end tag. <Name>Europa Growth Fund</Name> is well-formed; <Name>Europa Growth Fund is not.
• Elements nest properly. <a><b></b></a> is well-formed; <a><b></a></b> is not.
• Element and attribute names are case-sensitive. <Fund> and <fund> are different elements.
• Attribute values are always quoted. Single or double quotes are both allowed: id="EGF-001" and id='EGF-001' are equivalent.
• Five characters are reserved and must be escaped when they appear as text: < becomes <, > becomes >, & becomes &, " becomes ", and ' becomes '.

An element with no content can be written as <ShareClass></ShareClass> or, equivalently, as the empty-element form <ShareClass/>. Parsers treat the two forms as identical.

A well-formed document is not necessarily a useful document: it may still violate a schema, contain the wrong fields, or carry impossible values. Well-formedness is the bottom rung of the validation ladder, not the top.

2.3.2 Elements versus attributes

One of the oldest debates in XML design is the choice between expressing a piece of information as a child element or as an attribute. Consider two hypothetical ways of writing a fund's base currency (these are general XML illustrations, not FundsXML elements):

<!-- As a child element -->
<Fund>
  <BaseCurrency>EUR</BaseCurrency>
</Fund>

<!-- As an attribute -->
<Fund baseCurrency="EUR"/>

Both carry the same information. The working rules of thumb, applied consistently throughout FundsXML and throughout the examples in this book, are:

• Use elements for data, attributes for metadata. The currency of a fund is data; the version of a schema or the identifier of a document is metadata about the document itself.
• Use elements when the value may later need sub-structure. A fund name today is a string; tomorrow it might need a language tag or a sort form. Elements can grow children; attributes cannot.
• Use attributes for values that qualify the enclosing element without being part of its content. The id on a record, the unit of a measurement, the version of a format.
• Prefer elements when in doubt. FundsXML leans heavily towards elements, and the habit of reaching for an element first is the safer default for a practitioner.

Illustrated on a hypothetical share-class element (not the actual FundsXML element, which uses Identifiers/ISIN and Names/OfficialName instead):

<ShareClass id="EGF-001-ACC-EUR" currency="EUR">
  <ISIN>LU0000000001</ISIN>
  <Name xml:lang="en">Europa Growth Fund, Accumulating, EUR</Name>
  <Name xml:lang="de">Europa Growth Fund, Thesaurierend, EUR</Name>
</ShareClass>

Here id and currency are qualifiers — they tell us which share class and in what unit — while the ISIN and the two Name elements carry the share class's own data. Note how the element form of Name naturally accommodates two languages; an attribute form could not. The real FundsXML schema resolves this design question consistently in favour of elements: the currency is always a child element <Currency>EUR</Currency>, not an attribute.

2.3.3 Text, mixed content, CDATA, and comments

Element content falls into three categories. An element may contain only other elements (element-only content, the usual case for structured data such as a portfolio), only text (text-only content, typical for leaf fields such as <ISIN>), or a mixture (mixed content, in which text and child elements are interleaved). Mixed content is common in fact-sheet prose and regulatory narrative text, but rare in portfolio and transaction structures.

A short fact-sheet paragraph might look like this:

<InvestmentPolicy xml:lang="en">
  The fund invests primarily in large-capitalisation European equities
  and uses a <Benchmark>MSCI Europe NR</Benchmark> as its reference.
</InvestmentPolicy>

When text must contain characters that XML would otherwise interpret — for example, a literal < or & — two escape mechanisms are available. The first is the entity-reference mechanism already mentioned (<, &). The second is a CDATA section, which tells the parser "everything inside here is raw text, don't try to interpret it":

<LegalText><![CDATA[
  The management fee is 1.25% per annum of the NAV
  & is accrued daily.
]]></LegalText>

CDATA is most useful when embedding pre-formatted text, such as an HTML fragment or a legal notice, that contains many XML-special characters.

Comments are written <!-- like this --> and are ignored by parsers. They are invaluable in schemas and in hand-edited sample files, but should not be relied upon to carry information that downstream consumers need, because many XML tool chains discard them silently. Processing instructions of the form <?target data?> also exist; FundsXML does not use them beyond the XML declaration itself, and a practitioner need only recognise them.

---

2.4 Character Encoding and the XML Declaration

The first line of almost every XML file is the XML declaration:

<?xml version="1.0" encoding="UTF-8"?>

Three things are worth knowing about it.

First, the declaration is strictly optional under XML 1.0 when the encoding is UTF-8 or UTF-16, but in practice every serious tool chain emits it. Always include it.

Second, the encoding attribute tells the parser how the bytes in the file map onto characters. UTF-8 is the default in practice and should be the default in your own production of FundsXML files. The alternatives — ISO-8859-1, Windows-1252, UTF-16 — are legacy choices that cause avoidable pain, most commonly when a German umlaut, a French accent, or a non-breaking space survives a round trip through a tool chain that guesses the encoding wrongly.

Third, UTF-8 files may be preceded by a three-byte byte-order mark (the BOM, EF BB BF). Some Windows tools write the BOM by default; some Unix tools refuse to parse a file that begins with it. Neither behaviour is strictly wrong, but the combination is a reliable source of production incidents. The safe rule for FundsXML work is: emit UTF-8 without a BOM, and treat the appearance of a BOM in an incoming file as a yellow flag worth investigating.

Encoding is not an academic concern for the fund industry. Multi-lingual fund names, legal disclaimers with em-dashes and typographic quotes, and regulatory text with accented characters all pass through the same pipeline as the numbers. A single mis-configured character set turns Société Générale into Société Générale, and a downstream regulator is unlikely to laugh.

---

2.5 Namespaces

2.5.1 Why namespaces exist

As soon as XML documents began to combine data from multiple sources, a practical problem emerged. Two independently designed vocabularies might both use an element called Name, or Address, or Type. Without some way of telling them apart, a document that mixed them would be ambiguous.

XML namespaces solve this by giving every element and attribute a two-part name: a namespace URI (which acts as a globally unique identifier) and a local name (the short name used in the document). Two elements share a name only if both parts match.

2.5.2 Declaring and using namespaces

A namespace is bound to a prefix (or to the default) by an xmlns attribute:

<Fund xmlns="http://example.org/illustrative/fund"
      xmlns:sig="http://www.w3.org/2000/09/xmldsig#">
  <Name>Europa Growth Fund</Name>
  <sig:Signature>
    <!-- digital signature content, treated in Chapter 9 -->
  </sig:Signature>
</Fund>

Two namespaces are in play here. The default namespace, declared by xmlns="..." without a prefix, applies to <Fund> and <Name>. The second namespace is bound to the prefix sig: and applies to <sig:Signature>. A consumer that understands both vocabularies can process each subtree independently.

Three points deserve emphasis because they are the source of most namespace-related confusion:

• The URI is an identifier, not an address. Nothing lives at http://example.org/illustrative/fund. The URI is chosen for uniqueness, not for retrieval. FundsXML's own namespace URIs follow the same convention.
• Prefixes are local aliases, not part of the name. The same document could write xmlns:f="http://example.org/illustrative/fund" and then use <f:Fund> instead of <Fund>; both forms identify the same element. Tools that compare XML must compare the expanded names, not the prefixed ones.
• Default namespaces propagate to descendants. Once a default namespace is declared on an element, every unprefixed descendant element is in that namespace — until an inner element redeclares it. Attributes are not covered by the default namespace; an unprefixed attribute is in no namespace at all. This asymmetry surprises newcomers and is worth remembering.

2.5.3 Namespace-aware tooling

A recurring field-failure pattern around FundsXML is the use of a tool that is not namespace-aware. Such tools treat <f:Fund> and <Fund> as different elements purely on the basis of the textual prefix, and produce XPath queries that silently return empty results against files whose authors happen to have chosen a different prefix. Every tool shown in this book — xmllint, oXygen, IntelliJ, VS Code, and the FreeXmlToolkit treated in Chapter 11 — is namespace-aware. If you ever find yourself writing an XPath expression against a FundsXML document that matches nothing despite an obvious element being present, the first diagnosis should always be: am I missing a namespace binding?

---

2.6 From Well-Formed to Valid: Enter XSD

Well-formedness asks whether a document obeys XML's syntactic rules. Validity asks a stronger question: does the document obey the rules of some particular vocabulary? Those rules — which elements may appear, in what order, how often, with what types of content, and with what attributes — are written in a schema, and the act of checking a document against that schema is schema validation.

XML has more than one schema language. Three are worth knowing by name:

• DTD (Document Type Definition) is the original schema language, inherited from SGML. It is expressive but crude: it has no notion of data types beyond "string", no namespace support worth using, and a syntax that is not itself XML. DTDs survive in legacy corners of publishing and HTML but are a historical curiosity for FundsXML purposes.
• Relax NG is an elegant, pattern-based schema language that is technically superior to XSD in several ways and is used, for example, by OpenDocument. Its weaker tooling support in enterprise environments has limited its adoption in financial standards.
• XSD (XML Schema Definition), governed by the W3C, is the schema language FundsXML uses. It is itself an XML vocabulary — meaning schemas can be parsed by the same tools that parse instance documents — and it supports a rich type system, namespaces, inheritance, and modularisation.

FundsXML chose XSD for pragmatic reasons. XSD is supported by every serious XML tool, every major programming language, and every enterprise integration platform. Its type system is expressive enough to enforce formats such as ISIN, date, and decimal precision, and its modularisation features scale to the dozens of schema files that make up a modern FundsXML release. No other schema language would have been as durable a choice in 2001, and none has meaningfully displaced it in the two decades since.

The rest of this chapter therefore teaches XSD, and only XSD. When the book speaks of "the schema" from Chapter 3 onwards, it means an XSD schema.

---

2.7 XSD Simple Types

XSD divides types into two categories. A simple type is a type that constrains a single leaf value — the text content of an element or the value of an attribute. A complex type describes the structure of an element with child elements and attributes. This section treats simple types; §2.8 treats complex types.

2.7.1 Built-in simple types

XSD provides several dozen built-in simple types. A fund-industry practitioner needs to recognise the following core set on sight:

Table 2.1 — Core XSD built-in types for fund data

Type	Purpose	Example value
xs:string	Arbitrary text	Europa Growth Fund
xs:normalizedString	Text with whitespace normalised	Europa Growth Fund
xs:token	Text with leading, trailing, and multiple internal whitespace collapsed	EUR
xs:boolean	true / false (or 1 / 0)	true
xs:decimal	Arbitrary-precision decimal number	123.456789
xs:integer	Whole number	42
xs:double	64-bit floating point	1.2345E3
xs:date	ISO-8601 date	2026-04-30
xs:dateTime	ISO-8601 date with time and optional timezone	2026-04-30T17:30:00+02:00
xs:gYear	A four-digit year	2026
xs:anyURI	A URI (used for namespace references and links)	http://example.org/f
xs:ID / xs:IDREF	A unique identifier / a reference to one	EGF-001

A few observations matter for fund data. xs:decimal is the correct type for monetary values and NAVs: it is arbitrary-precision and does not suffer from the rounding surprises of xs:double. xs:date and xs:dateTime require ISO-8601 format — year-month-day, not the assorted national variants; a pipeline that accepts 30/04/2026 is accepting something that is not a valid xs:date. xs:boolean accepts true, false, 1, and 0, and nothing else; values like Y or Yes are invalid.

2.7.2 Restricting built-in types

The real power of XSD simple types comes from restrictions (formally called constraining facets): building a new simple type by constraining an existing one. XSD defines twelve constraining facets, and each facet is applicable only to certain families of types. Table 2.2 gives the complete picture.

Table 2.2 — XSD constraining facets at a glance

Facet	Applies to	Effect
enumeration	all types	Value must be one of a listed set
pattern	all types	Value must match a regular expression
whiteSpace	string types	Controls whitespace handling: preserve, replace, or collapse
length	string, binary, list types	Value must have exactly this length
minLength	string, binary, list types	Value must have at least this length
maxLength	string, binary, list types	Value must have at most this length
minInclusive	numeric, date/time types	Value must be ≥ this bound
minExclusive	numeric, date/time types	Value must be > this bound
maxInclusive	numeric, date/time types	Value must be ≤ this bound
maxExclusive	numeric, date/time types	Value must be < this bound
totalDigits	xs:decimal and derived	Maximum total number of digits
fractionDigits	xs:decimal and derived	Maximum number of fractional digits

Several facets can be combined in a single restriction — for example, a pattern and a maxLength on the same type. The XSD processor checks every facet; the value must satisfy all of them.

The following worked examples, drawn from Europa Growth Fund data, illustrate each family of facets.

String restrictions: pattern, length, minLength, maxLength

An ISIN pattern. An ISIN is exactly twelve characters: two letters (the country code), followed by nine alphanumeric characters, followed by one decimal digit (the check digit). The XSD that expresses this is:

<xs:simpleType name="ISINType">
  <xs:restriction base="xs:string">
    <xs:pattern value="[A-Z]{2}[A-Z0-9]{9}[0-9]"/>
  </xs:restriction>
</xs:simpleType>

A value of LU0000000001 validates; a value of LU000000000 (eleven characters) does not, and neither does lu0000000001 (lowercase country code). The pattern facet uses the regular-expression syntax defined by XSD, which is similar to — but not identical with — the Perl-style regular expressions most programmers know. The most important differences are that XSD patterns always match the entire value (no need for ^ and $ anchors) and that some shorthand character classes differ.

A bounded text field. Many FundsXML text fields carry a maximum-length constraint to prevent absurdly long values from reaching the consumer. A typical text field limited to 256 characters:

<xs:simpleType name="Text256Type">
  <xs:restriction base="xs:string">
    <xs:maxLength value="256"/>
  </xs:restriction>
</xs:simpleType>

For an exact-length field — a two-letter ISO country code, for example — the length facet is more appropriate than the combination of minLength and maxLength:

<xs:simpleType name="ISOCountryCodeType">
  <xs:restriction base="xs:string">
    <xs:length value="2"/>
    <xs:pattern value="[A-Z]{2}"/>
  </xs:restriction>
</xs:simpleType>

Here length and pattern work together: the value must be exactly two characters and must consist of two uppercase letters. Either facet alone would be insufficient — length alone would accept 12, and pattern alone would accept ABC if the expression were written carelessly.

Enumeration: enumeration

A currency enumeration. ISO 4217 defines the three-letter alphabetic currency codes. A minimal enumeration covering the currencies in which the Europa Growth Fund issues share classes might be:

<xs:simpleType name="CurrencyType">
  <xs:restriction base="xs:string">
    <xs:enumeration value="EUR"/>
    <xs:enumeration value="USD"/>
    <xs:enumeration value="CHF"/>
    <xs:enumeration value="GBP"/>
    <xs:enumeration value="JPY"/>
  </xs:restriction>
</xs:simpleType>

In production, the enumeration would cover the complete ISO 4217 list. The principle is the same: an enumeration is the correct way to pin a field to a closed set of values, and it costs nothing at runtime. Enumerations are not limited to strings — they work on any type. An enumeration of xs:integer values, for example, can restrict a field to a fixed set of numeric codes.

Numeric restrictions: minInclusive, maxInclusive, minExclusive, maxExclusive, totalDigits, fractionDigits

A NAV decimal constraint. A NAV per share must be non-negative, and a practitioner may reasonably insist on no more than eight fractional digits:

<xs:simpleType name="NavType">
  <xs:restriction base="xs:decimal">
    <xs:minInclusive value="0"/>
    <xs:fractionDigits value="8"/>
  </xs:restriction>
</xs:simpleType>

The schema rejects -1.0 and 123.123456789 (nine fractional digits); it accepts 123.45 and 0.

The difference between inclusive and exclusive bounds is exactly what the names suggest. minInclusive value="0" accepts zero; minExclusive value="0" does not. A percentage field that must be strictly between 0 and 100 would use:

<xs:simpleType name="PercentageType">
  <xs:restriction base="xs:decimal">
    <xs:minExclusive value="0"/>
    <xs:maxExclusive value="100"/>
  </xs:restriction>
</xs:simpleType>

The totalDigits facet limits the total number of significant digits (before and after the decimal point), which is useful for monetary amounts where the database column has a fixed precision:

<xs:simpleType name="MonetaryAmountType">
  <xs:restriction base="xs:decimal">
    <xs:totalDigits value="18"/>
    <xs:fractionDigits value="2"/>
  </xs:restriction>
</xs:simpleType>

This type accepts up to sixteen digits before the decimal point and exactly two after — sufficient for any fund-industry amount.

Date and time restrictions: range bounds on xs:date and xs:dateTime

The same minInclusive, maxInclusive, minExclusive, and maxExclusive facets that constrain numbers also constrain dates and date-times. A type for a ContentDate that must lie within the twenty-first century:

<xs:simpleType name="ReportingDateType">
  <xs:restriction base="xs:date">
    <xs:minInclusive value="2000-01-01"/>
    <xs:maxExclusive value="2100-01-01"/>
  </xs:restriction>
</xs:simpleType>

This catches the occasional data-entry error that produces a date in 1026 instead of 2026 — a surprisingly common incident in production.

Whitespace handling: whiteSpace

The whiteSpace facet controls how the XSD processor normalises whitespace before checking other constraints. Three values are available:

• preserve — whitespace is left untouched (the default for xs:string).
• replace — every tab, carriage return, and newline is replaced with a single space.
• collapse — like replace, but leading and trailing spaces are also stripped and sequences of multiple spaces are collapsed to one.

In practice, collapse is the most useful for fund data, because it prevents invisible whitespace from causing downstream mismatches:

<xs:simpleType name="CleanTokenType">
  <xs:restriction base="xs:string">
    <xs:whiteSpace value="collapse"/>
    <xs:maxLength value="64"/>
  </xs:restriction>
</xs:simpleType>

Note that the built-in type xs:token already applies collapse semantics, so a whiteSpace facet is typically needed only when restricting xs:string directly.

Combining facets

Facets compose freely within the limits of applicability. A real-world FundsXML type might combine several:

<xs:simpleType name="LEIType">
  <xs:restriction base="xs:string">
    <xs:length value="20"/>
    <xs:pattern value="[A-Z0-9]{18}[0-9]{2}"/>
  </xs:restriction>
</xs:simpleType>

A Legal Entity Identifier is exactly twenty characters: eighteen alphanumeric characters followed by two check digits. Both the length and the pattern are enforced; a value that satisfies one but not the other is rejected.

2.7.3 Lists and unions

Two further simple-type constructions are occasionally useful. An xs:list type describes a whitespace-separated list of values of another simple type — a natural fit for, say, a list of ISINs on a single line. An xs:union type describes a value that may belong to any of several simple types — a natural fit for a field that is either a known enumerated code or a free-form override. Both are used sparingly in FundsXML; you will encounter them rarely and should simply recognise the construction when you do.

---

2.8 XSD Complex Types and Structuring

A complex type describes an element that has structure: child elements, attributes, or both. It is where the shape of the document is defined. For fund data, almost every element beyond the leaves is a complex type.

2.8.1 The basic form

The workhorse complex type declaration uses xs:sequence to say "these children, in this order":

<xs:complexType name="FundType">
  <xs:sequence>
    <xs:element name="Name"          type="xs:string"/>
    <xs:element name="Domicile"      type="xs:string"/>
    <xs:element name="BaseCurrency"  type="CurrencyType"/>
    <xs:element name="ShareClasses"  type="ShareClassesType"/>
  </xs:sequence>
  <xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>

This type, together with the earlier CurrencyType and a ShareClassesType we will define in a moment, fully describes the <Fund> element from §2.2. The use="required" on the attribute says that the id attribute must be present.

Note the strong reminder: this FundType is an illustrative hand-rolled type for teaching XSD complex-type syntax. The real FundsXML FundType, with its Identifiers, Names, Currency, SingleFundFlag, FundStaticData, FundDynamicData, and SingleFund/Subfunds choice, is the subject of Chapter 5 and is documented precisely in Appendix C.

2.8.2 Occurrence constraints

Every element declaration can specify how many times it may appear by using minOccurs and maxOccurs. The defaults are 1 and 1 — exactly once, mandatory. Common variations are:

• minOccurs="0" — optional element;
• minOccurs="0" maxOccurs="unbounded" — zero or more, the typical shape for a repeated child such as a list of share classes;
• minOccurs="1" maxOccurs="unbounded" — one or more;
• explicit numbers — for example, a type that insists on exactly twelve monthly returns would use minOccurs="12" maxOccurs="12".

A ShareClassesType that contains one or more <ShareClass> children is therefore:

<xs:complexType name="ShareClassesType">
  <xs:sequence>
    <xs:element name="ShareClass"
                type="ShareClassType"
                minOccurs="1" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

2.8.3 Sequence, choice, and all

xs:sequence is the most common compositor, but it is not the only one.

• xs:sequence specifies children in a fixed order.
• xs:choice specifies that exactly one of several alternatives must appear — used, for example, when a position can be described either by its ISIN or by a bundle of descriptive fields, but not both.
• xs:all specifies that a fixed set of children must each appear exactly once, in any order. It is less often useful than xs:sequence and has some restrictions in XSD 1.0 that have limited its adoption.

Compositors can nest: an xs:sequence can contain an xs:choice that contains another xs:sequence, and so on. FundsXML makes extensive use of this nesting to express "either a simple reference to an asset, or a full inline description".

2.8.4 Derivation: extension and restriction

XSD supports two forms of type derivation. Extension adds children or attributes to an existing type — the XSD equivalent of subclassing with additional fields. Restriction narrows an existing type — the equivalent of tightening a contract.

Extension is the more common of the two in fund data. For example, a hypothetical EquityPositionType might extend a generic PositionType by adding equity-specific fields:

<xs:complexType name="EquityPositionType">
  <xs:complexContent>
    <xs:extension base="PositionType">
      <xs:sequence>
        <xs:element name="Sector" type="xs:string"/>
        <xs:element name="DividendYield" type="xs:decimal" minOccurs="0"/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

Derivation supports substitution groups and abstract types, which are the mechanism by which FundsXML models "many kinds of position" inside a single portfolio container. Chapter 6 returns to this pattern when it covers the portfolio section in detail.

2.8.5 Global, local, and anonymous

A simple or complex type can be declared globally, at the top level of the schema, with a name attribute, and then referenced by its name from wherever it is needed. It can also be declared locally, anonymously, inside the element declaration it describes. Global types are reusable and make a schema easier to read; anonymous inline types are briefer but cannot be referred to from elsewhere.

FundsXML leans towards global types for anything more than a one-off leaf, and this book follows the same convention in its examples.

---

2.9 Structuring Larger Schemas

A production schema for a complex domain is never a single file. FundsXML distributes its definitions across several dozen files grouped by concern — control data, funds, portfolios, regulatory modules, and so on. Two mechanisms allow XSD files to refer to one another.

xs:include merges another schema file into the current one, under the same namespace. It is the natural choice for splitting a single logical schema into multiple physical files for readability. If Fund.xsd defines the fund-level types and ShareClass.xsd defines share-class types, and both live in the same namespace, then Fund.xsd includes ShareClass.xsd:

<xs:include schemaLocation="ShareClass.xsd"/>

xs:import is used when the imported schema lives in a different namespace. This is the mechanism by which FundsXML references third-party vocabularies such as XMLDSig for digital signatures or the FinDatEx regulatory templates, each of which has its own namespace. An import must mention the foreign namespace explicitly:

<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
           schemaLocation="xmldsig-core-schema.xsd"/>

A third, more obscure mechanism — the chameleon schema — lets a schema without its own target namespace be included into another and take on the including schema's namespace. It is rare in modern practice and is mentioned here only so that you recognise the name if you encounter it.

Chapter 3 will walk through FundsXML's actual file layout and explain which files import which. For the present chapter, the takeaway is simpler: when you open a schema and see xs:include or xs:import at the top, you are looking at a composition of several files, and a complete picture of any element's definition may require following the links.

---

2.10 XML Validation in Practice

Schema validation is the act of checking that an instance document matches a schema. Every mainstream XML tool chain — every IDE plugin, every command-line utility, every library in every programming language — supports it. Performing validation early and often is the single most effective discipline a FundsXML practitioner can adopt.

2.10.1 Two error classes

Validation produces errors of two very different kinds, and learning to distinguish them is half the battle.

Well-formedness errors are syntactic: the file is not even XML. Typical messages are "mismatched tag", "attribute value not quoted", "premature end of data", or "encoding error". A well-formedness error means no further validation is possible — the parser cannot build a tree.

Schema validity errors are structural: the file is valid XML but does not match the schema. Typical messages are "element X not expected here", "attribute Y is required but missing", "value Z does not match pattern", or "element W has invalid child element V".

The distinction matters because the two classes of error are fixed differently. A well-formedness error is almost always the result of a tool that was not designed to emit XML — a template-based generator, a hand edit, a buggy library. A schema validity error is almost always a semantic mismatch: the producer's understanding of the vocabulary diverged from the schema's.

2.10.2 Validating from the command line

The simplest production-grade validator is xmllint, part of the libxml2 library that ships with every modern Linux and macOS system and is readily installed on Windows. A one-line validation against a schema looks like this:

xmllint --noout --schema Fund.xsd Fund.xml

The --noout flag suppresses the default behaviour of reprinting the document on success; without it, a successful validation floods the terminal with the document's content. On success, xmllint prints Fund.xml validates; on failure, it prints a line-numbered description of each error and exits with a non-zero status.

For continuous-integration pipelines, this is all that is needed. A shell script that loops over the outbound FundsXML files and runs xmllint against the schema catches the vast majority of problems at the cheapest possible point — before the files leave the building.

2.10.3 Reading a validation error

Consider a deliberately broken share class, in which the ISIN has been corrupted:

<ShareClass>
  <ISIN>LU000000000X</ISIN>
  <Currency>EUR</Currency>
</ShareClass>

Validated against the ISINType defined in §2.7.2, this produces an error along the following lines:

Fund.xml:7: element ISIN: Schemas validity error :
  Element 'ISIN': [facet 'pattern'] The value 'LU000000000X'
  is not accepted by the pattern '[A-Z]{2}[A-Z0-9]{9}[0-9]'.

Three pieces of information matter in this message. The file-and-line prefix (Fund.xml:7) points at the offending element. The bracketed facet name ([facet 'pattern']) says which restriction rejected the value — here, the regular expression pattern. The value itself (LU000000000X) is quoted back so you can compare it to your expectation. Together, these three are enough to diagnose most schema-level errors without reading the schema at all.

2.10.4 What schema validation does not catch

Schema validation is powerful but limited. It answers the question is this document structurally correct? — not the question is this document semantically reasonable? A well-formed, schema-valid FundsXML document may still:

• have a NAV that is positive but implausibly large;
• describe a share class whose currency does not match the base currency of the fund and whose hedged flag is false;
• reference an asset by UniqueID that does not appear elsewhere in the document;
• declare a fund-total that does not equal the sum of its position values.

Catching these requires a second layer of checking — business-rule validation — which FundsXML implementations typically perform using Schematron or hand-written code. Chapter 10 develops the two-stage validation model in full. For now, it is enough to note that schema validation is necessary but not sufficient, and that no FundsXML production pipeline should ever rely on schema validation alone.

---

2.11 XPath

Once you have a FundsXML document, you will want to pull specific values out of it. The tool for that job is XPath, a compact expression language for navigating the XML tree. XPath is the query language behind almost every XML technology: XSLT, XQuery, Schematron, and the XML facilities of every mainstream programming language. A solid understanding of XPath makes every later chapter of this book easier to follow.

2.11.1 The tree model

XPath sees an XML document as a tree. Every piece of the document is a node, and nodes come in seven kinds:

Node type	Example	Notation in XPath
Document (root)	the document itself	/
Element	<Fund>	Fund
Attribute	ccy="EUR"	@ccy
Text	the characters between tags	text()
Comment	<!-- … -->	comment()
Processing instruction	<?xml-stylesheet …?>	processing-instruction()
Namespace	xmlns:xsi="…"	namespace::xsi

For fund-data work, element, attribute, and text nodes account for 99 per cent of all queries. An XPath expression starts at a context node and walks the tree from there, producing a node set — a collection of zero or more nodes.

2.11.2 Navigation: paths, steps, and shortcuts

Absolute paths start with a single / at the document root and walk downward by element name:

• /FundsXML4 — the root element.
• /FundsXML4/ControlData/ContentDate — the content date of the delivery.
• /FundsXML4/Funds/Fund — every Fund element under the root.

Relative paths start from the current context node. In most command-line tools, the context node is the document root, so the effect is the same as an absolute path; inside XSLT templates and predicates, the context node is whatever node the template is currently processing.

The double-slash // is the most-used shortcut in practice. It means "anywhere below", at any depth:

• //ShareClass — every ShareClass element, regardless of where it sits in the tree.
• //ISIN — every ISIN, however deeply nested.

The dot . refers to the current context node; the double dot .. refers to the parent node. Both are used constantly inside predicates and XSLT:

• . — the current node.
• .. — the parent of the current node.
• ../Currency — the Currency sibling of the current node's parent.

Attribute access uses the @ prefix:

• //Amount/@ccy — the ccy attribute of every Amount element.
• //@ccy — every ccy attribute anywhere in the document.

Wildcards select nodes regardless of name:

• //Fund/* — every direct child element of every Fund, whatever the element name.
• //@* — every attribute in the document.
• //Fund/node() — every child node (elements, text, comments) of every Fund.

Text access uses text():

• //ISIN/text() — the string value of every ISIN element.

2.11.3 Predicates and filtering

Predicates, in square brackets, filter node sets by arbitrary conditions. They are the WHERE clause of XPath.

Value comparisons:

• //ShareClass[Currency='EUR'] — share classes whose Currency child has text content EUR.
• //Fund[Identifiers/LEI='549300ABCDEFGHIJ1234'] — the fund whose LEI matches.
• //Position[MarketValue > 1000000] — positions with a market value above one million.

Positional predicates:

• //ShareClass[1] — the first share class (XPath positions start at 1, not 0).
• //ShareClass[last()] — the last.
• //ShareClass[position() <= 3] — the first three.

Existence tests — a predicate that names a path is true if the path selects at least one node:

• //ShareClass[Identifiers/ISIN] — share classes that have an ISIN.
• //Fund[not(FundDynamicData)] — funds that have no dynamic data.

Compound predicates combine conditions with and, or, and not():

• //Position[MarketValue > 1000000 and Currency='EUR'] — EUR positions above one million.
• //ShareClass[Currency='EUR' or Currency='CHF'] — EUR or CHF share classes.

Chained predicates apply successive filters:

• //ShareClass[Currency='EUR'][1] — the first EUR share class.

2.11.4 Axes: navigating in every direction

Each step in an XPath expression uses an axis that determines the direction of travel through the tree. Most of the time the axis is implicit — Fund/Currency is shorthand for Fund/child::Currency — but the full axis syntax is needed when you must navigate sideways or upward.

Table 2.4 — XPath axes

Axis	Direction	Shorthand	Example
child::	direct children	(default)	child::Fund = Fund
attribute::	attributes	@	attribute::ccy = @ccy
parent::	parent node	..	parent::Fund
self::	current node	.	self::Fund
descendant::	all descendants	—	descendant::ISIN
descendant-or-self::	self + descendants	//	descendant-or-self::node()
ancestor::	all ancestors	—	ancestor::Fund
ancestor-or-self::	self + ancestors	—	ancestor-or-self::Funds
following-sibling::	later siblings	—	following-sibling::ShareClass
preceding-sibling::	earlier siblings	—	preceding-sibling::ShareClass
following::	everything after	—	following::Fund
preceding::	everything before	—	preceding::Fund

The axes that matter most for fund-data work are child (the default), attribute (@), parent (..), descendant-or-self (//), and following-sibling / preceding-sibling. A practical example: given a Position element, find the fund it belongs to:

• ancestor::Fund/Names/OfficialName — walks up the tree to the enclosing Fund and then back down to its name.

2.11.5 Functions

XPath 1.0 provides a compact function library. The functions most relevant to fund-data work fall into four groups.

String functions:

Function	Purpose	Example
concat(a, b, …)	Concatenate strings	concat(//LEI, ' — ', //OfficialName)
contains(s, sub)	Test if s contains sub	//Fund[contains(Names/OfficialName, 'Growth')]
starts-with(s, pre)	Test if s starts with pre	//ISIN[starts-with(., 'LU')]
substring(s, pos, len)	Extract substring	substring(//ISIN, 1, 2) → country code
string-length(s)	Length of string	//Name[string-length(.) > 100]
normalize-space(s)	Strip and collapse whitespace	normalize-space(//OfficialName)
translate(s, from, to)	Character-by-character replacement	translate(//Currency, 'abcdefghijklmnopqrstuvwxyz', 'ABCDEFGHIJKLMNOPQRSTUVWXYZ')

Numeric functions:

Function	Purpose	Example
sum(node-set)	Sum of numeric values	sum(//Position/MarketValue)
count(node-set)	Number of nodes	count(//ShareClass)
round(n)	Round to nearest integer	round(//NavPerShare)
floor(n)	Round down	floor(//NavPerShare)
ceiling(n)	Round up	ceiling(//NavPerShare)
number(s)	Convert to number	number(//TotalNetAssetValue/Amount)

Boolean functions:

Function	Purpose	Example
not(expr)	Logical negation	//Fund[not(FundDynamicData)]
true() / false()	Boolean constants	predicate building blocks
boolean(expr)	Convert to boolean	boolean(//ISIN) → true if any ISIN exists

Node functions:

Function	Purpose	Example
name()	Element name (with prefix)	//Fund/*[name()='Currency']
local-name()	Element name (without prefix)	useful in namespaced documents
namespace-uri()	Namespace URI of the node	debugging namespace issues

Illustrated against the Europa Growth Fund document from §2.2: count(//ShareClass) returns 2, sum(//ShareClass/NavPerShare) returns the sum of per-share NAVs, and concat(//OfficialName, ' (', //Currency, ')') returns Europa Growth Fund (EUR).

2.11.6 Operators and expressions

XPath expressions support arithmetic, comparison, boolean logic, and the union operator.

Arithmetic — +, -, *, div, mod:

• //MarketValue div //TotalNetAssetValue/Amount * 100 — position weight as a percentage.
• count(//Position) mod 2 — is the number of positions odd or even?

Note that division uses div, not /, because / is already taken as the path separator.

Comparison — =, !=, <, >, <=, >=:

• //Position[Quantity > 10000] — positions with more than ten thousand units.
• //TotalAssetValue[NavDate = '2026-03-31'] — the asset value for a specific date.

When used inside XML attributes (as in XSLT), the < character must be escaped as <.

Boolean logic — and, or, not():

• //Position[Quantity > 10000 and MarketValue > 5000000] — large positions by both measures.

Union — | combines two node sets:

• //Fund/Names/OfficialName | //Fund/Names/ShortName — all official and short names together.

2.11.7 XPath and namespaces

XPath 1.0 matches elements by their expanded name (namespace URI + local name), not by their textual prefix. When a document uses a namespace — as many real XML documents do — your XPath tooling must be told which prefix in the query stands for which namespace URI. Every XPath-capable tool has its own way of declaring the binding; the mechanism differs, but the obligation is the same. An XPath query written without a namespace binding against a namespaced document is the single most common source of "no results, but I can see the element right there" frustration.

2.11.8 XPath versions

XPath has evolved through several versions, and the differences matter for tool selection.

XPath 1.0 (1999) is the version described in this section. It is universally supported by every XML library, every IDE, and every command-line tool. It works with node sets, strings, numbers, and booleans. For the purposes of reading and querying FundsXML, it is sufficient.

XPath 2.0 (2007) adds a richer type system (sequences instead of node sets, typed values aligned with XSD), if/then/else expressions, for expressions, quantified expressions (some/every), and a much larger function library including regular-expression matching (matches(), replace(), tokenize()). It is the version used by XSLT 2.0, XQuery, and Schematron.

XPath 3.0 / 3.1 (2014/2017) adds higher-order functions (functions as values), the let expression, arrow operator (=>), inline functions, and maps and arrays. It is used by XSLT 3.0 and XQuery 3.1.

For day-to-day FundsXML work, XPath 1.0 covers the vast majority of queries. XPath 2.0 becomes useful when writing Schematron business rules (Chapter 10) or complex XSLT transformations (§2.12), where its richer type system and matches() function simplify the work considerably.

---

2.12 XSLT Transformations

XSLT — the Extensible Stylesheet Language Transformations — is the standard way of turning one XML document into another document, which may itself be XML, HTML, CSV, plain text, or almost anything else. In a FundsXML context, XSLT is how a single canonical fund-data document becomes a fact-sheet HTML fragment, a distributor-specific CSV, a regulatory submission, or a formatted printout.

2.12.1 The mental model

An XSLT stylesheet is itself an XML document. It contains a set of templates, each of which says "when you encounter a node that matches this pattern, produce this output". The processor walks the input tree, matches each node against the templates in turn, and writes the output. The model is declarative, not imperative: you describe the mapping, and the processor decides how to traverse the source.

The three templates you will see most often are xsl:template, which defines a match rule; xsl:apply-templates, which tells the processor to recursively process child nodes; and xsl:value-of, which inserts the string value of a node into the output.

2.12.2 Example: FundsXML to CSV

Here is a minimal stylesheet that turns the Europa Growth Fund document from §2.2 into a two-column CSV of ISINs and currencies:

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="text" encoding="UTF-8"/>

  <xsl:template match="/FundsXML4">
    <xsl:text>ISIN;Currency&#10;</xsl:text>
    <xsl:apply-templates select="Funds/Fund/SingleFund/ShareClasses/ShareClass"/>
  </xsl:template>

  <xsl:template match="ShareClass">
    <xsl:value-of select="Identifiers/ISIN"/>
    <xsl:text>;</xsl:text>
    <xsl:value-of select="Currency"/>
    <xsl:text>&#10;</xsl:text>
  </xsl:template>
</xsl:stylesheet>

The xsl:output method="text" declaration switches the processor into plain-text mode, so that the output is written directly without XML escaping. The root template matches the FundsXML4 root element, writes a header line, and then delegates to the share-class template for each ShareClass child. The share-class template writes one CSV line per input share class. Against the §2.2 document the result is:

ISIN;Currency
LU1234567890;EUR
LU1234567892;CHF

A real counterparty feed, of course, requires more columns. The following stylesheet produces a richer export that includes the fund name, the share-class name, the LEI of the fund, and the NAV date — all the fields a distributor typically needs in a daily share-class listing:

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="text" encoding="UTF-8"/>

  <xsl:template match="/FundsXML4">
    <xsl:text>FundName;LEI;ISIN;ShareClassName;Currency;NavDate&#10;</xsl:text>
    <xsl:apply-templates select="Funds/Fund"/>
  </xsl:template>

  <xsl:template match="Fund">
    <xsl:variable name="fundName" select="Names/OfficialName"/>
    <xsl:variable name="lei"      select="Identifiers/LEI"/>
    <xsl:variable name="navDate"
      select="FundDynamicData/TotalAssetValues/TotalAssetValue/NavDate"/>
    <xsl:for-each select="SingleFund/ShareClasses/ShareClass">
      <xsl:value-of select="$fundName"/>
      <xsl:text>;</xsl:text>
      <xsl:value-of select="$lei"/>
      <xsl:text>;</xsl:text>
      <xsl:value-of select="Identifiers/ISIN"/>
      <xsl:text>;</xsl:text>
      <xsl:value-of select="Names/OfficialName"/>
      <xsl:text>;</xsl:text>
      <xsl:value-of select="Currency"/>
      <xsl:text>;</xsl:text>
      <xsl:value-of select="$navDate"/>
      <xsl:text>&#10;</xsl:text>
    </xsl:for-each>
  </xsl:template>
</xsl:stylesheet>

Two new XSLT features appear. First, xsl:variable captures values from the enclosing Fund node so that they can be reused inside the inner xsl:for-each loop without repeating the full XPath each time. Second, xsl:for-each iterates over the share classes directly rather than delegating to a separate template — a stylistic choice that works well when the logic is short and self-contained. Against the §2.2 document the output is:

FundName;LEI;ISIN;ShareClassName;Currency;NavDate
Europa Growth Fund;549300ABCDEFGHIJ1234;LU1234567890;Europa Growth Fund I EUR Acc;EUR;2026-03-31
Europa Growth Fund;549300ABCDEFGHIJ1234;LU1234567892;Europa Growth Fund R CHF Acc Hedged;CHF;2026-03-31

This is the beating heart of the distribution pipeline. Every bilateral CSV feed in an unstandardised production, of the kind Chapter 1 catalogued, can be replaced by a single canonical FundsXML file plus one XSLT per counterparty. If Distributor A wants semicolons and Distributor B wants tabs, the difference is a single character in one xsl:text element. Changes to any one counterparty touch one stylesheet and nothing else.

2.12.3 Example: FundsXML to fact-sheet HTML

A second stylesheet produces a fact-sheet page from the same Europa Growth Fund document. Unlike the CSV, this time the output is a complete HTML document with a title, a summary table of fund-level metadata, and a share-class listing:

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="html" indent="yes" encoding="UTF-8"/>

  <xsl:template match="/">
    <xsl:variable name="fund" select="/FundsXML4/Funds/Fund"/>
    <xsl:variable name="nav"
      select="$fund/FundDynamicData/TotalAssetValues/TotalAssetValue
              /TotalNetAssetValue/Amount"/>
    <html>
      <head><title><xsl:value-of select="$fund/Names/OfficialName"/></title></head>
      <body>
        <h1><xsl:value-of select="$fund/Names/OfficialName"/></h1>
        <table border="1" cellpadding="4">
          <tr><td>LEI</td>
              <td><xsl:value-of select="$fund/Identifiers/LEI"/></td></tr>
          <tr><td>Currency</td>
              <td><xsl:value-of select="$fund/Currency"/></td></tr>
          <tr><td>NAV</td>
              <td><xsl:value-of select="$nav"/>
                  <xsl:text> </xsl:text>
                  <xsl:value-of select="$nav/@ccy"/></td></tr>
          <tr><td>NAV Date</td>
              <td><xsl:value-of select="$fund/FundDynamicData
                    /TotalAssetValues/TotalAssetValue/NavDate"/></td></tr>
          <tr><td>Content Date</td>
              <td><xsl:value-of
                    select="/FundsXML4/ControlData/ContentDate"/></td></tr>
        </table>

        <h2>Share classes</h2>
        <table border="1" cellpadding="4">
          <tr><th>ISIN</th><th>Name</th><th>Currency</th></tr>
          <xsl:for-each select="$fund/SingleFund/ShareClasses/ShareClass">
            <tr>
              <td><xsl:value-of select="Identifiers/ISIN"/></td>
              <td><xsl:value-of select="Names/OfficialName"/></td>
              <td><xsl:value-of select="Currency"/></td>
            </tr>
          </xsl:for-each>
        </table>
      </body>
    </html>
  </xsl:template>
</xsl:stylesheet>

Several things are worth noting. The root template matches / rather than /FundsXML4; either form works, but matching the document root is slightly more idiomatic when the stylesheet produces a complete HTML page. The $fund and $nav variables keep the XPath expressions short and readable inside the template body. The $nav/@ccy expression reads the ccy attribute from the Amount element, so the currency appears next to the value without being hard-coded.

The method="html" output declaration switches the processor into HTML-serialisation mode, which is subtly different from XML: empty elements like <br> are written without the self-closing slash, boolean attributes are written bare, and character references are emitted in a form that browsers expect. Against the §2.2 document, the result is a self-contained HTML page whose summary table reads:

LEI	549300ABCDEFGHIJ1234
Currency	EUR
NAV	464552848.78 EUR
NAV Date	2026-03-31
Content Date	2026-03-31

and whose share-class table lists both share classes with their ISINs, names, and currencies. A production fact sheet would add styling, logos, and far more data — but the principle is the same: the XSLT carries the layout logic, and the FundsXML document supplies the data.

2.12.4 Example: data-quality checks with XSLT

The examples so far transform FundsXML into a different format — CSV, HTML. But XSLT can just as well transform a document into a report about itself. This opens the door to a lightweight data-quality layer: encode your business rules as an XSLT stylesheet, run it against every incoming file, and inspect the output for violations.

Consider one of the most fundamental fund-data invariants: the sum of the market values of all portfolio positions must equal the fund's total net asset value on the same date. If a FundsXML file carries both a TotalNetAssetValue and a set of Position elements with TotalValue amounts, the following stylesheet checks whether they agree:

<xsl:stylesheet version="1.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="text" encoding="UTF-8"/>

  <xsl:template match="/FundsXML4">
    <xsl:for-each select="Funds/Fund">
      <xsl:variable name="fundName" select="Names/OfficialName"/>
      <xsl:variable name="fundCcy"  select="Currency"/>
      <xsl:variable name="fundNAV"
        select="FundDynamicData/TotalAssetValues/TotalAssetValue
                /TotalNetAssetValue/Amount[@ccy = $fundCcy]"/>
      <xsl:variable name="positionSum"
        select="sum(FundDynamicData/Portfolios/Portfolio
                /Positions/Position/TotalValue/Amount[@ccy = $fundCcy])"/>
      <xsl:variable name="diff" select="$fundNAV - $positionSum"/>

      <xsl:value-of select="$fundName"/>
      <xsl:text>&#10;  Fund NAV:      </xsl:text>
      <xsl:value-of select="$fundNAV"/>
      <xsl:text> </xsl:text>
      <xsl:value-of select="$fundCcy"/>
      <xsl:text>&#10;  Position sum:  </xsl:text>
      <xsl:value-of select="$positionSum"/>
      <xsl:text> </xsl:text>
      <xsl:value-of select="$fundCcy"/>
      <xsl:text>&#10;  Difference:    </xsl:text>
      <xsl:value-of select="$diff"/>
      <xsl:choose>
        <xsl:when test="$diff = 0">
          <xsl:text>&#10;  Result:        PASS&#10;</xsl:text>
        </xsl:when>
        <xsl:when test="$diff &gt; -1 and $diff &lt; 1">
          <xsl:text>&#10;  Result:        PASS (rounding)&#10;</xsl:text>
        </xsl:when>
        <xsl:otherwise>
          <xsl:text>&#10;  Result:        FAIL&#10;</xsl:text>
        </xsl:otherwise>
      </xsl:choose>
    </xsl:for-each>
  </xsl:template>
</xsl:stylesheet>

The stylesheet iterates over every Fund in the document, computes the sum of position values in the fund's own currency, and compares it with the reported total NAV. A difference below one currency unit is accepted as a rounding tolerance; anything larger is flagged as FAIL. The output is plain text, easily piped into a log file or a monitoring system:

Europa Growth Fund
  Fund NAV:      464552848.78 EUR
  Position sum:  464552848.78 EUR
  Difference:    0
  Result:        PASS

The same principle scales to any business rule that can be expressed as a combination of XPath queries: does every share class carry an ISIN?, is the NAV date consistent with the content date?, do percentage allocations sum to 100? Each rule becomes one additional block in the stylesheet. The output can be plain text, as above, or HTML for a visual dashboard — or even XML, if the quality report is to be consumed by another automated step.

This approach has a practical advantage: it requires nothing beyond an XSLT 1.0 processor, which is already available on every platform (§2.12.6). There is no need to learn a separate validation language. For organisations that prefer a more formal, standards-based approach to business-rule validation, Schematron — which Chapter 10 covers in detail — provides a dedicated assertion language on top of XPath and can be compiled to XSLT automatically. But for teams that already know XSLT, writing quality checks directly is a natural and effective starting point.

The FundsXML working group maintains a public repository of ready-to-use XSLT stylesheets for data-quality checking at github.com/fundsxml/examples. It includes both a basic five-section check (XSLT 2.0) and a comprehensive ten-section HTML dashboard (XSLT 1.0) that covers NAV reconciliation, share-class price verification, percentage-allocation checks, asset-specific validations, and more. These stylesheets can be used as-is against any FundsXML 4.x document or adapted to an organisation's specific rules.

2.12.5 The identity transform

One small but powerful idiom deserves mention. The identity transform is a stylesheet that simply copies its input to its output unchanged:

<xsl:template match="@*|node()">
  <xsl:copy>
    <xsl:apply-templates select="@*|node()"/>
  </xsl:copy>
</xsl:template>

Combined with one or two additional templates that override specific nodes, the identity transform is the standard way of making surgical changes to a FundsXML document — for example, renaming a single element or stripping a specific attribute — without touching anything else. Any XSLT tutorial that goes beyond a few pages will show it again and again.

2.12.6 Versions

XSLT exists in three main versions. XSLT 1.0 is universally supported and is enough for almost every practical FundsXML transformation a fund practitioner will write. XSLT 2.0 adds sequences, richer types, and grouping constructs. XSLT 3.0 adds streaming (important for very large documents) and higher-order functions. The code in this book uses XSLT 1.0 unless explicitly noted; if you have access to a 2.0 or 3.0 processor, you lose nothing by running 1.0 stylesheets on it.

---

2.13 Tools for Day-to-Day XML Work

A practitioner need not build tools from scratch; a rich ecosystem already exists. This section gives the lie of the land; Chapter 11 revisits the tools in depth, with installation guides, configuration advice, and feature-by-feature comparisons.

Table 2.2 — XML tooling at a glance

Tool	Kind	Strengths	Treated in depth
xmllint	Command-line	Validation, formatting, XPath; ships with libxml2; free	§2.10, Chapter 10
oXygen XML Editor	Commercial IDE	Visual schema design, schema-aware editing, XSLT debugging	Chapter 11
Altova XMLSpy	Commercial IDE	Visual design, generation, data mapping	Chapter 11
IntelliJ IDEA / Ultimate	General IDE	Strong XML and XSD support, integrated validation	Chapter 11
VS Code (+ XML plugins)	General editor	Free; lightweight; good validation with the Red Hat XML plugin	Chapter 11
Eclipse (+ Web Tools)	General IDE	Schema view, XML editors, free	Chapter 11
FreeXmlToolkit	FundsXML-aware	Purpose-built for FundsXML workflows	Chapter 11

Two points about this table matter now. First, all of these tools are namespace-aware and all support XSD validation against the FundsXML schemas. The choice between them is, to a first approximation, a choice of ergonomics and cost, not of capability. Second, the free options — xmllint, VS Code with the Red Hat plugin, and the FreeXmlToolkit — are enough to reach a fully operational FundsXML pipeline. The commercial IDEs become attractive when schema authoring and visual data mapping become part of the daily workflow, not merely schema consumption.

Beyond this chapter. A knowledgeable reader will notice that this chapter has stopped short of several valid XML topics: XML Catalogs, XInclude, XPointer, XQuery, Schematron, the XSD 1.1 assertion facility, SOAP and WSDL, and XSLT 2.0/3.0 features. None of them are needed to read, validate, or transform FundsXML, and each has been omitted deliberately to keep the chapter short. Where a later chapter reaches for one of them — Schematron in Chapter 10, XMLDSig in Chapter 9 — we will introduce it at that point, in the context where it matters.

---

2.14 Common Pitfalls

Every experienced FundsXML practitioner keeps a mental list of recurring traps. The list below is not exhaustive, but it covers the failures that appear most frequently in production.

• Encoding mismatches. A file declared as UTF-8 but actually written as Windows-1252 will parse — until the first accented character. Always emit UTF-8, always read it with a UTF-8-aware parser, and never paste text between editors that disagree on their default encoding.
• The byte-order mark. A BOM at the start of a UTF-8 file is legal but is rejected by some downstream tools and silently corrupts some others. Configure your editor to save UTF-8 without a BOM.
• Namespace-unaware XPath. If an XPath query returns an empty result set against a document in which the element is clearly present, the first check is whether the namespace has been declared to the XPath processor. It almost always has not.
• Attribute vs element confusion. Two producers of the same logical data choose differently — one writes <Currency>EUR</Currency>, the other <Amount currency="EUR">100</Amount> — and a consumer that expects one form silently ignores the other. The schema is authoritative; read it.
• Decimal-separator locale. A decimal number written as 1.234,56 is not an xs:decimal. European locales that use the comma for the decimal separator and the period for the thousands separator must convert before emitting XML.
• Whitespace and the silent trim. xs:token collapses internal whitespace; xs:string preserves it. An ISIN that someone has appended a stray trailing space to will fail a pattern validation but can pass an xs:token comparison — or vice versa, depending on the order.
• Case-sensitivity of enumerations. EUR, eur, and Eur are three different values to an XSD enumeration. Converting incoming free text to a normalised form before validating is a defensive habit worth acquiring.
• Comments as data. Comments are stripped by many processors. Do not put anything in a comment that you expect to be available downstream.
• Large files and memory. A DOM-based parser loads the entire document into memory. For the hundreds-of-megabytes files that a fund-of-funds look-through can produce, a streaming parser (SAX, StAX, or XSLT 3.0 streaming) is the right tool.

Each of these pitfalls has cost someone a production incident at some point. Recognising the pattern in your own pipelines is half the defence.

---

2.15 Key Takeaways

• XML represents data as a tree of named elements that may carry attributes and contain text; the whole technical apparatus of this chapter is layered on top of this simple model.
• A document is well-formed if it obeys XML's syntactic rules, and valid if it additionally matches a schema. Well-formedness is a precondition for validation; validation is the first line of defence against production errors.
• XML namespaces give elements and attributes globally unique identities, and XSD is the schema language in which FundsXML is written; together they enable the composition of independently maintained vocabularies into a single document.
• XSD simple types — with restrictions such as pattern, enumeration, minInclusive, and fractionDigits — are the correct mechanism for enforcing formats like ISIN, currency, and NAV precision.
• XSD complex types, built from xs:sequence, xs:choice, xs:all, and element occurrences, describe the shape of every non-leaf element. Type derivation lets specialised types extend or restrict general ones, and xs:include and xs:import stitch large schemas together from many files.
• Schema validation is powerful but partial; semantic rules that XSD cannot express belong to a second, business-rule validation layer that Chapter 10 develops in full.
• XPath in its 1.0 dialect is enough for almost every fund-data query a practitioner will need to write, and XSLT 1.0 is enough for almost every transformation.
• A small, well-chosen toolchain — a namespace-aware editor, a command-line validator such as xmllint, and a FundsXML-aware tool such as the FreeXmlToolkit — is all the equipment required to work productively with FundsXML. Chapter 11 revisits each tool in depth.

With the XML and XSD vocabulary in place, we are ready to look at FundsXML itself — its history, its organisation, its architecture, and its schema layout — which is the subject of Chapter 3.

↑ Top

FundsXML — The Standard at a GlanceHistory, organisation, and architecture

---

3.1 Setting the Scene: From Syntax to Substance

Chapter 1 made the case for a shared standard. Chapter 2 introduced XML and XSD as the technologies on which such a standard can be built. We now bring those two threads together and ask the obvious next question: what exactly is FundsXML?

Return once more to the Europa Growth Fund. After the month-end episode that opened this book, and after a thirty-page crash course in XML, the operations team gathers around a whiteboard for what the head of operations calls a "ten-minute orientation". The team has, by this point, read a number of FundsXML deliveries with a text editor and even run one or two against a schema validator. They can see that the files are well-formed and, mostly, that they are valid. What they still cannot see is the shape of the thing as a whole. Where did this schema come from? Who decides what belongs in it and what does not? How are the pieces arranged, and why in that particular way? Unless these questions are answered first, every later chapter of this book will feel like a tour through rooms whose floor plan the reader has never seen.

This chapter is that floor plan. It closes Part I of the book with a deliberately high-altitude view of FundsXML. We tell the story of how the standard came into being and who maintains it today; we distil the design principles that shape every FundsXML message; and we draw a mental map of the five main areas of the schema. No field-level detail appears here — that begins in Chapter 4. The aim is orientation, not completeness: by the end of the chapter the reader should be able to look at any FundsXML document, identify the five main areas, and know which later chapter of this book covers each of them.

By the end of this chapter, you should be able to:

• tell the story of FundsXML from its German origins in 2001 through to the current 4.2.x release of 2026;
• name the bodies and working groups that maintain the standard and explain how a change gets into the schema;
• state the five core design principles that shape every FundsXML delivery;
• draw, from memory, a mental map of the five main schema areas — ControlData, Funds, AssetMasterData, Documents, and RegulatoryReportings — and recognise how they fit together;
• read a short FundsXML document skeleton on sight and point at the area each part belongs to.

The chapter is built around three questions — where does FundsXML come from?, who runs it?, and what does it look like? — in that order. Readers in a hurry may skim §3.2 and §3.3 and concentrate on §3.4 to §3.6, which are the structural core of the chapter and the foundation for Part II.

---

3.2 A Brief History of FundsXML

Standards never arrive out of nowhere. They are always the answer to a concrete industrial problem, and the character of the answer is shaped by the people who formulated the question. FundsXML is no exception. Its story falls naturally into three waves: a German origin phase, a European expansion that crossed national borders, and a regulatory era driven by the wave of EU fund-related legislation of the last decade.

3.2.1 Origins: Germany, 2001–2005

FundsXML was created in 2001 by a group of major German-speaking fund-management houses seeking a common format for the fund-data they all had to exchange with one another. The founding participants were Allianz Global Investment, COMINVEST (later absorbed into Allianz Global Investment), Credit Suisse Asset Management, DEKA, DWS, and Union Investment, with early technical support from Vontobel, the Swiss software vendor K&W Software AG, and FERI TRUST. The immediate trigger was neither regulatory nor ideological; it was operational. Each of these houses managed thousands of fund records, and each bilateral channel to a distributor, a depositary, a data vendor, or the financial press used a different CSV layout, a different Excel template, or a different proprietary format. Every new distribution contract added a new mapping, and every mapping had to be maintained forever.

The initial response was pragmatic. A small working group drafted a lightweight XML vocabulary that described the master data and daily price data of a fund, agreed on it informally, and began to use it in production. There was no standards body at first, no formal certification, and no public repository — only a shared schema file, a shared understanding of what the elements meant, and a willingness to keep the format stable for long enough that the investment in implementation would pay off. This informal start left two enduring marks on the standard's character: a preference for practical problem-solving over theoretical elegance, and an instinct for backwards compatibility that has survived every subsequent revision.

The informal phase did not last long. By late 2003, the BVI (Bundesverband Investment und Asset Management e.V.), the German fund-industry association, had recognised that its members needed a single supported standard for fund-data exchange and formally adopted the effort. Version 1.0 of FundsXML was published on 8 December 2003 under BVI stewardship. That publication is the moment at which FundsXML ceased to be a private inter-company schema and became a named, versioned industry standard.

3.2.2 European Expansion: 2006–2013

The German origin did not stay German for long. Beginning in 2006, the Austrian investment-fund community joined the initiative: VÖIG (Vereinigung Österreichischer Investmentgesellschaften), the Oesterreichische Kontrollbank (OeKB), and ERSTE-SPARINVEST KAG brought FundsXML into Austria and established the German-Austrian co-stewardship that still defines the standard's governance today. The chair of the FundsXML Standards Committee is to this day held by BVI, with VÖIG serving as deputy — an arrangement that reflects the order in which the two national communities joined rather than any weighting of their importance.

The pace of European adoption accelerated from there. In 2007, Robeco carried FundsXML into the Netherlands. In 2008, two further national communities joined simultaneously: DIAMS (FundsXML France) brought the standard into France, and the Danish Investment Association IFR adopted it under the FundConnect project for Denmark. The same year, version 3.0 was published on 30 October 2008, consolidating several rounds of extensions into a single release. In 2009, La Banque Postale Asset Management of Paris became the first major French adopter. In 2010, the AFG (Association Française de la Gestion Financière, the French fund-industry association) endorsed the standard, and Fundsquare brought it into Luxembourg. KNEIP, also of Luxembourg, followed in 2011, and AXA France Investment Managers in 2012.

The decisive European moment came in 2013, when EFAMA — the European Fund and Asset Management Association — recommended FundsXML as the standard format for the Fund Processing Passport (FPP), the pan-European framework for communicating the essential operational data of a fund to its distributors. EFAMA's endorsement moved FundsXML from "a widely-used industry schema" to "the European Fund Association's recommended format", and it placed the standard at the centre of cross-border fund distribution from that point onwards.

3.2.3 Regulatory Era and Version 4.x: 2014–2026

The third phase of FundsXML's history is the one most readers of this book will have lived through. Between 2014 and the present, the European fund industry was reshaped by a cascade of regulatory initiatives — MiFID II, PRIIPs, the SFDR and the broader sustainable-finance package, IDD, Solvency II — each of which demanded structured data of a kind that no legacy interface could provide. The FinDatEx consortium, supported by the major European industry associations, responded by publishing a series of templates: the European MiFID Template (EMT), the European PRIIPs Template (EPT), the European ESG Template (EET), the European Feedback Template (EFT), and the Tripartite Template (TPT) for Solvency II. These templates solved the semantic problem — which fields must be exchanged and with what meaning — but they said little about how the fields should travel between systems.

FundsXML became the natural carrier. The major architectural opportunity to make it so was the 4.0.0 release in 2017 — the first release since the original drafting that was deliberately not backward-compatible with earlier versions. Version 4.0 re-thought the top-level structure, introduced the separation of static and dynamic fund data that the standard still uses today, and cleaned up a number of historical compromises that had accumulated through the 3.x line. Subsequent 4.x releases then absorbed the FinDatEx templates one after another into the RegulatoryReportings area of the schema, so that a single FundsXML delivery could transport the classical master data, the portfolio, the transactions, and the regulatory templates in one envelope. This simple architectural decision — same envelope, different freights — is the reason FundsXML has become, in practice, the de-facto European interchange format for structured fund data.

The 4.2 line, first released in May 2022 as version 4.2.0, consolidated this approach and added the connections to the European Single Access Point (ESAP) that Chapter 8 will discuss in detail. Eleven minor releases (4.2.0 through 4.2.10) have followed between 2022 and early 2026, each adding fields, tightening constraints, or tracking new FinDatEx template versions — without breaking the instance documents that earlier releases produced. The book you are holding describes the 4.2.x line and is accurate as of version 4.2.10.

Table 3.1 — Key Milestones in the History of FundsXML

Year	Event	Significance
2001	FundsXML created by Allianz Global Investment, COMINVEST, Credit Suisse Asset Management, DEKA, DWS, and Union Investment; early support from Vontobel, K&W Software AG, and FERI TRUST	Birth of the standard as a private inter-company schema among major German-speaking fund houses
2003	BVI adopts the standard; Version 1.0 published on 8 December 2003	Transition from a private schema to a named industry standard under German fund-association stewardship
2006	VÖIG, OeKB, and ERSTE-SPARINVEST bring FundsXML into Austria	Establishment of the German-Austrian co-stewardship that still defines governance today
2007	Robeco adopts FundsXML in the Netherlands	First expansion beyond German-speaking Europe
2008	DIAMS (FundsXML France) and the Danish Investment Association IFR (FundConnect) adopt the standard; Version 3.0 released on 30 October 2008	Simultaneous entry into France and Denmark; first major consolidating release
2009	La Banque Postale Asset Management adopts the standard	First major French asset-management adopter
2010	AFG endorses FundsXML; Fundsquare adopts it in Luxembourg	Endorsement by the French fund-industry association; entry into Luxembourg
2011	KNEIP adopts the standard in Luxembourg	Expansion within the Luxembourg fund-services ecosystem
2012	AXA France Investment Managers adopts the standard	Further French adoption
2013	EFAMA recommends FundsXML as the standard format for the Fund Processing Passport (FPP)	Recognition as the European Fund Association's recommended fund-data format
2017	FundsXML 4.0.0 released	First major architectural reset; deliberately not backward-compatible; introduces the static/dynamic separation
2022	FundsXML 4.2.0 released (4 May 2022)	Current major line; consolidated FinDatEx template integration and ESAP preparation
2026	Current 4.2.10 line	The version this book describes

Two final observations on the history are worth keeping in mind. First, FundsXML did not originate in Brussels. It was not imposed on the industry by a regulator, nor designed in a policy vacuum by a standards body with no operational stake. It grew out of the day-to-day practice of fund operations teams in six of Germany's largest asset-management houses in 2001, was picked up and formalised by their industry association (BVI) in 2003, and was extended into Austria, the Netherlands, France, Denmark, and Luxembourg over the following decade. This bottom-up genealogy explains a great deal about the standard's character: it is pragmatic, it is extensible, and it is, sometimes, a little idiosyncratic in places where a top-down design would have been tidier.

Second, the standard's evolution has been strictly additive for most of its recent history. Since the 4.0 reset, no subsequent release has broken existing instance documents in a way that required users to rewrite their producers or consumers; new modules have been added, old modules have been extended, and deprecated constructs have been retained alongside their replacements for several release cycles before removal. This conservative release discipline is another reason FundsXML has survived while less patient projects have not.

---

3.3 The Organisation Behind the Standard

A living standard needs a living organisation. The question every new FundsXML user eventually asks is who decides? — who decides what goes into the next release, who decides when that release is cut, and who the reader should contact if something in the schema is wrong. This section answers those questions in four short subsections.

3.3.1 The FundsXML Association

FundsXML is maintained by a registered, not-for-profit industry association whose members are drawn from every role in the European fund value chain: asset managers, fund administrators, depositary banks, data vendors, software houses, and a small number of consultancies. Membership is open, contributions are voluntary, and decisions are taken transparently within the working groups and formalised by the FundsXML Standards Committee (FSC). No single vendor or jurisdiction owns the standard, and no commercial license is required to implement it — both the schema and its documentation are freely available.

This governance model matters in practice. It means that a fund house in Warsaw or Helsinki can join a working group on equal terms with a depositary bank in Frankfurt; it means that a software vendor building a FundsXML parser does not need to negotiate redistribution rights; and it means that the standard's future direction is determined by the people who use it in production, rather than by a committee detached from the operational reality.

3.3.2 Working Groups and the Release Cycle

Strategic direction and maintenance of the standard are the responsibility of the FundsXML Standards Committee (FSC), whose members are drawn from thirteen leading fund-industry organisations across Austria, Denmark, France, Germany, Luxembourg, the Netherlands, and Switzerland. The FSC decides on new memberships, creates and dissolves working groups, and — critically — decides on the release and realisation of working-group results. Day-to-day standardisation work is delegated to three dedicated working groups, summarised in Table 3.2.

Table 3.2 — FundsXML Working Groups

Working group	Scope	Typical outputs
Content & Technique	Manages the XML schema, defines data structures, ensures robustness and consistency of the standard	Schema releases, data-structure definitions
Promotion	Visibility and adoption of FundsXML across Europe through marketing, public relations, and member engagement	Conferences, outreach material, adoption campaigns
Documentation	Implementation guides, code examples, and schema references	Published guides, sample files, reference documentation

The release cycle follows the familiar semantic pattern. Patch releases within a 4.2.x line contain clarifications, documentation fixes, and strictly non-breaking adjustments — existing instance documents continue to validate unchanged. Minor releases (4.2, 4.3, and so on) add new elements or new modules but preserve backwards compatibility for anything that was already present. Major releases (the next of which would be 5.0) are reserved for architectural changes that cannot be made compatibly, and the association's policy is to avoid them unless no alternative exists — the 4.x line is now more than fifteen years old, which is a deliberate commitment rather than an accident.

The path a change takes from proposal to release is straightforward. Any member may raise a change request in the relevant working group. The Content & Technique working group discusses it, refines it, and — if the change is substantive — produces a draft schema update together with test files and a short rationale. The draft is then circulated to all members for review, adjusted in response to comments, and, if accepted by the FSC, scheduled into a release window. A release window is announced in advance so that implementers can plan their own update cycles; the release itself ships the new schema, a changelog, updated sample files, and any new or updated validation rules together as a single coordinated package.

3.3.3 Where the Standard Lives

FundsXML is, from a technical point of view, a small number of files: the XSD schemas, a collection of sample documents, a changelog, and supporting documentation. All of these are published openly. The authoritative home of the standard is the official website and the associated public source-code repository, where each release is tagged, signed, and accompanied by release notes. The issue tracker on the same repository is the canonical place to report bugs, request clarifications, or propose changes that are not yet mature enough for a working-group agenda.

This book deliberately does not print URLs in the running text; software and infrastructure change faster than books do. Appendix E collects the current set of official links, and the reader is encouraged to treat that appendix as the authoritative pointer whenever the present chapter says "the official site" or "the public repository".

3.3.4 Community and Events

Beyond the formal machinery of working groups and releases, FundsXML has a small but active community of practitioners who exchange knowledge at workshops, industry conferences, and informal meet-ups. Training material, webinars, and hands-on sessions are organised by the association itself and occasionally by member firms. For most readers of this book, the relevant point is simply that help exists and is reachable: a question asked in the right place usually receives a reasoned answer from someone who has already solved the same problem in production.

Taken together, the association, the working groups, the public repository, and the community form a lightweight but functional ecosystem. FundsXML is not a finished document to be consumed; it is a living project to which any serious implementer can, and occasionally should, contribute.

---

3.4 Design Principles

Before we turn to the schema itself, we pause to name the five principles that shape it. None of them is unique to FundsXML — every mature data standard wrestles with the same trade-offs — but the particular combination is characteristic, and recognising the principles in advance makes the structure of the schema considerably easier to read. These five principles reappear, explicitly or implicitly, in every chapter of Part II.

1. Separation of static and dynamic data. FundsXML distinguishes the information about a fund that rarely changes — its name, its ISIN, its domicile, its investment policy — from the information that changes every valuation day — its NAV, its portfolio composition, its transaction flow. The two are carried in different substructures of the same Fund element, which allows a producer to ship a lean daily delta without re-transmitting the entire static record and allows a consumer to cache the static part between deliveries. This principle is visible in the schema as the pairing of FundStaticData and FundDynamicData, which Chapter 5 explores in detail.
2. Linkage by UniqueID, not by nesting. A fund's portfolio may reference hundreds of distinct instruments, and a single instrument — say, a blue-chip European equity — may appear in the portfolios of many funds within the same delivery. Rather than repeat the full description of that instrument at every position where it occurs, FundsXML places each instrument once in a central AssetMasterData section and refers to it from every portfolio position by a UniqueID. The effect is to normalise the document, much as a relational database normalises a schema: the same information lives in one place and is referenced from wherever it is needed.
3. Extensibility through CustomAttributes. No standard can enumerate every field that every member firm, in every jurisdiction, will ever need. FundsXML acknowledges this openly by providing a schema-sanctioned extension mechanism — the CustomAttributes element — that allows a producer to attach named key–value data to most structural elements without breaking the schema. National specialties, proprietary risk metrics, internal reference codes, and early experiments with new fields all live here without forcing a fork of the schema. Chapter 9 treats CustomAttributes in depth and explains how to use it responsibly.
4. Multi-language by design. European fund distribution is inherently multilingual: the same fund may be sold in eleven countries under the same ISIN with eleven different marketing names and eleven versions of the same investment-policy description. FundsXML treats language as a first-class attribute of textual fields, so that a single delivery can carry names, classifications, and descriptions in several languages in parallel. There is no need to produce a separate file per language or to pick a canonical translation at the producer and hope the consumer accepts it.
5. Modular regulatory carriers. EMT, EPT, EET, EFT, and TPT each have their own semantics, their own release cadence, and their own community. FundsXML does not attempt to rewrite them; it embeds them as self-contained modules within a RegulatoryReportings area, so that each can evolve on its own schedule while travelling in the same envelope as the core fund data. The envelope is stable; the freights are allowed to change independently.

These five principles are the mental scaffolding on which the rest of the book rests. When, in a later chapter, a piece of the schema looks surprising, ask which of the principles it serves: nine times out of ten, the answer explains the design.

---

3.5 Schema Architecture at a Glance

We are now ready to look at the shape of FundsXML itself. This section is deliberately a map, not a tutorial. For each main area we give the purpose, the kind of content that lives inside it, the single most important idea to carry forward, and a forward pointer to the chapter of this book in which the area is treated in detail. No field listings, no code samples, no XPath expressions — those start in Chapter 4.

A FundsXML document has a single root element, conventionally named FundsXML4, and beneath that root live five main areas. These areas are the subject of Chapters 4 to 9. Figure 3.1 shows them schematically.

Figure 3.1 — The Five Main Areas of a FundsXML Document

                             ┌─────────────────┐
                             │    FundsXML4    │  (root)
                             └────────┬────────┘
                                      │
       ┌─────────────┬────────────────┼─────────────────┬───────────────────┐
       │             │                │                 │                   │
┌──────┴──────┐ ┌────┴─────┐ ┌────────┴────────┐ ┌──────┴──────┐ ┌──────────┴───────────┐
│ ControlData │ │  Funds   │ │ AssetMasterData │ │  Documents  │ │ RegulatoryReportings │
│ (envelope)  │ │ (subject │ │  (reference     │ │ (factsheets │ │  (EMT/EPT/EET/…)     │
│             │ │  of msg) │ │   library)      │ │  & signed   │ │                      │
│             │ │          │ │                 │ │  attach.)   │ │                      │
└─────────────┘ └────┬─────┘ └────────▲────────┘ └─────────────┘ └──────────────────────┘
                     │                │
                     │ Portfolio      │ UniqueID
                     │ positions ─────┘ reference
                     │
                     └── Transactions (inside FundDynamicData)

The diagram makes two points worth stating in words. First, Portfolios and Transactions are not siblings of the five main areas; they live inside the Funds area, more precisely inside each Fund's FundDynamicData. Newcomers often expect Portfolio and Transactions as top-level root children and are briefly disoriented when they are not — remembering their position inside Funds saves a surprising amount of confusion later. Second, the arrow from Portfolio positions up into AssetMasterData is the graphical form of design principle 2: a position does not carry its own asset description; it references one, by UniqueID, in the central library.

We now walk through each of the five areas in the order a reader encounters them in a real delivery.

3.5.1 ControlData — The Envelope

ControlData is the envelope of every FundsXML delivery. It carries the metadata about the message rather than the substance within it: a unique document identifier, the reporting date to which the delivery refers, the creation timestamp, the identity of the data sender and the intended receiver, the language of the delivery, and — crucially — the DataOperation flag that tells the consumer whether the file represents an initial load, an update to a previous delivery, or a deletion. Every FundsXML document contains exactly one ControlData element, and every downstream system reads it first.

The importance of ControlData is disproportionate to its size. It is the piece that allows a consumer to recognise, route, de-duplicate, and sequence a delivery; without it, the same file arriving twice would be indistinguishable from a genuine update, and a delivery arriving out of order would be impossible to reconcile against earlier ones. Chapter 4 walks through ControlData field by field and builds a complete, schema-valid example for the Europa Growth Fund.

3.5.2 Funds — The Subject of the Message

Funds is the area that most readers think of as "the FundsXML content proper". It contains one or more Fund elements, each representing a single legal fund or sub-fund, and within each Fund the structure splits — following design principle 1 — into FundStaticData and FundDynamicData. The static part describes the fund's identity: names in multiple languages, identifiers (ISIN, WKN, LEI, Valor), domicile, legal form, share-class structure, investment policy, benchmark, fees. The dynamic part describes the fund on a given valuation date: NAVs per share class, total net assets, performance figures, portfolio composition, and the day's transactions.

Share classes deserve a word here because they often cause the most friction for newcomers. A single fund in FundsXML may carry several share classes, each with its own ISIN, its own currency, its own distribution policy, and its own NAV; the fund's portfolio is typically shared across all share classes, while some of the dynamic figures are per-share-class. Chapter 5 is devoted entirely to the Funds area and uses the Europa Growth Fund, its three share classes, and their daily updates as a continuous example.

3.5.3 AssetMasterData — The Reference Library

AssetMasterData is the central reference library of a FundsXML delivery. It contains one entry per distinct instrument referenced anywhere in the delivery's portfolios, independent of how many times that instrument appears and in how many funds. Each entry gives the full static description of the instrument — asset class, identifiers, issuer, maturity where applicable, classification — and exposes a UniqueID by which portfolio positions can refer to it.

The value of AssetMasterData is exactly the value of normalisation in any database: the same information lives in one place, not many, and changes to an instrument's description need to be made once per delivery rather than hundreds of times per portfolio. The principle is important enough that Chapter 6 begins with a section on normalised referencing before it addresses individual asset classes.

3.5.4 Documents — Factsheets and Attachments

Documents is the area of the schema that most practitioners meet last, if at all, and yet it fills a surprisingly important role. It carries references to — or, in some deployments, the actual binary content of — fund-related documents that travel alongside the structured data: factsheets, prospectuses, key information documents (KIDs and KIIDs), sustainability-related disclosures, and audit reports. A Document entry names the document, classifies it, identifies the language and the effective date, and provides either a URL or an embedded representation.

The Documents area is also where FundsXML's support for XML digital signatures (XMLDSig) is rooted: a signed Document entry allows the producer to attest to the integrity and origin of an attached PDF in a way that survives transport through intermediate systems. Chapter 9 covers the Documents area together with signatures and country-specific additions.

3.5.5 RegulatoryReportings — The Regulatory Carriers

RegulatoryReportings is the area into which FundsXML absorbs the FinDatEx templates and related regulatory deliverables. It is organised as a container of self-contained modules, one per template: an EMT module for the European MiFID Template, an EPT for the PRIIPs template, an EET for the ESG template, an EFT for the Feedback template, and a TPT for the Solvency II Tripartite Template. Each module carries the fields that its template defines, with the same field names and the same data types, so that a FundsXML-aware consumer and a native template-aware consumer see the same data.

The architectural trick — and design principle 5 at work — is that FundsXML does not attempt to replace the templates. It carries them. When a template is revised by FinDatEx, the corresponding FundsXML module is updated in the next minor release without disturbing anything else in the delivery. Chapter 8 is the longest chapter in this book precisely because the regulatory carriers are where most of the day-to-day implementation effort goes.

A Summary Table

Table 3.3 — The Five Main Areas of FundsXML at a Glance

Area	Purpose in one sentence	Treated in
ControlData	Metadata of the delivery: who, when, for whom, which operation	Chapter 4
Funds	Static and dynamic fund data, share classes, portfolios, transactions	Chapters 5, 6, 7
AssetMasterData	Central reference library of instruments, addressed by UniqueID	Chapter 6
Documents	Factsheets, prospectuses, signed attachments	Chapter 9
RegulatoryReportings	EMT, EPT, EET, EFT, TPT as self-contained modules	Chapter 8

Table 3.3 is the single most important piece of Chapter 3 to keep within reach while reading the rest of the book. Whenever a later chapter refers to a "section" or a "module" of FundsXML, the table tells the reader where it sits in the overall picture.

---

3.6 A First FundsXML Skeleton

We close the architectural tour with the first real FundsXML fragment of the book. The listing below is a skeleton: it contains the element names and the hierarchy, but no values, no attributes beyond the namespace declaration, and no data beyond what is needed to show how the pieces fit together. No FundsXML validator would accept it, and no system would consume it. Its purpose is orientation, not execution.

<?xml version="1.0" encoding="UTF-8"?>
<FundsXML4 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:noNamespaceSchemaLocation="FundsXML4.xsd">

  <ControlData>
    <!-- document id, reporting date, sender, receiver, operation -->
  </ControlData>

  <Funds>
    <Fund>
      <FundStaticData>
        <!-- names, identifiers, domicile, share classes (static) -->
      </FundStaticData>
      <FundDynamicData>
        <TotalAssetValues>
          <!-- NAVs and total net assets per share class -->
        </TotalAssetValues>
        <Portfolios>
          <Portfolio>
            <Positions>
              <Position>
                <!-- references AssetMasterData by UniqueID -->
              </Position>
            </Positions>
          </Portfolio>
        </Portfolios>
        <SingleFundFlows>
          <!-- transactions: subscriptions, redemptions, distributions -->
        </SingleFundFlows>
      </FundDynamicData>
    </Fund>
  </Funds>

  <AssetMasterData>
    <Asset>
      <!-- one entry per distinct instrument, addressed by UniqueID -->
    </Asset>
  </AssetMasterData>

  <Documents>
    <!-- factsheets, prospectuses, KIDs, signed attachments -->
  </Documents>

  <RegulatoryReportings>
    <!-- EMT / EPT / EET / EFT / TPT modules -->
  </RegulatoryReportings>

</FundsXML4>

Even though the listing carries no real data, every design principle from §3.4 is visible in it. Principle 1 — the separation of static and dynamic data — appears as the pairing of FundStaticData and FundDynamicData inside the Fund element. Principle 2 — linkage by UniqueID — is the reason Positions holds only references and not instrument details, while the full instrument descriptions live once, in AssetMasterData, at the root level. Principle 3 — extensibility — is not printed above (we have left CustomAttributes out of the skeleton deliberately), but every major structural element in the real schema admits it. Principle 4 — multi-language support — is invisible in a skeleton without values, but the name and description fields inside FundStaticData will accept per-language variants when we fill them in. And principle 5 — modular regulatory carriers — is the reason RegulatoryReportings sits as its own top-level area alongside, rather than inside, the fund data it complements.

This is the last time in the book that a FundsXML sample will be this abstract. Beginning in Chapter 4, every listing carries real data for the Europa Growth Fund. Readers should note that the code listings in Chapters 4 through 8 are illustrative: element names, attribute values, and the precise field ordering are written for pedagogical clarity and do not always match the production schema down to the last character. Chapter 9 changes the rule and shows fully schema-validated examples against the current FundsXML 4.2.8 XSD, together with the xmllint commands that verify them. The complete, end-to-end example for the Europa Growth Fund is printed in Appendix D.

---

3.7 Key Takeaways

• FundsXML is not a regulatory imposition but a bottom-up industry standard. It was created in 2001 by six major German-speaking fund-management houses, adopted by BVI in 2003 (version 1.0 published on 8 December 2003), extended into Austria in 2006 under VÖIG, and expanded across Europe over the following decade. Today it is the de-facto European interchange format for structured fund data.
• The standard is maintained by an open, not-for-profit association whose working groups make decisions transparently and whose release discipline has kept the 4.x line backwards-compatible for more than fifteen years.
• Five design principles shape every FundsXML message: the separation of static and dynamic data, linkage by UniqueID rather than nesting, extensibility through CustomAttributes, multi-language support as a first-class feature, and modular regulatory carriers inside a stable envelope.
• A FundsXML document has one root and five main areas: ControlData (the envelope), Funds (the subject of the message), AssetMasterData (the reference library), Documents (factsheets and signed attachments), and RegulatoryReportings (EMT, EPT, EET, EFT, and TPT).
• Portfolios and Transactions are not top-level areas in their own right; they live inside each Fund's FundDynamicData. Positions reference AssetMasterData entries by UniqueID rather than repeating instrument details in place.
• Table 3.3 maps each of the five main areas to the chapter of this book that treats it in depth, and the reader may usefully keep it within reach while reading Part II.

With the map of the standard now in hand, we can zoom in on the first of the five areas — the envelope that every FundsXML delivery begins with. Chapter 4 turns to ControlData and walks through every field that identifies, dates, and routes a delivery in production.

↑ Top

ControlData — The Metadata of a DeliveryDocument ID, reporting date, sender, and operation type

---

4.1 Setting the Scene: Opening the Envelope

At the end of Chapter 3, the operations team at the Europa Growth Fund had a mental map of the five main areas of a FundsXML document. The most natural next question is not "how do we describe the fund?" — that is Chapter 5's subject — but rather "how do we describe the delivery itself?" Who sent it, when, on behalf of whom, for which reporting date, and — most importantly — what kind of delivery is it? A first-time load is not the same thing as an afternoon correction of a morning NAV; a regular monthly update is not the same thing as the retraction of a delivery that should never have gone out. FundsXML answers all of these questions in the small but disproportionately important structure that sits at the top of every document: ControlData.

Three reasons justify beginning Part II with the envelope rather than the fund itself. First, ControlData is the first element every consumer of a FundsXML file reads. A production pipeline that fails to understand ControlData never even gets to the fund data, let alone to the portfolios or regulatory modules. Second, ControlData is what makes a file identifiable, routable, and de-duplicable — without it, the same message arriving twice is indistinguishable from a genuine update, and a message arriving out of order is impossible to reconcile against what came before. Third, and most importantly, ControlData is where FundsXML takes its one explicit position on time — on how deliveries relate to one another across hours and days. That position is simple, deliberate, and not always what newcomers expect, and the six pages of §4.6 devoted to it are the conceptual core of this chapter.

By the end of this chapter, you should be able to:

• name every mandatory field of a ControlData block and explain what it identifies;
• produce a UniqueDocumentID that is unique across a producer's output stream for the life of the system;
• distinguish INITIAL, AMEND, and DELETE deliveries and choose the right one for a given operational situation;
• trace a chain of related deliveries backwards to the INITIAL that started it;
• recognise the half-dozen mistakes that cause the most production incidents in ControlData handling.

No prior knowledge of the FundsXML schema beyond Chapter 3 is assumed. The chapter proceeds from purpose to fields to operations: §4.2 describes what ControlData does in a live pipeline; §4.3 gives the field skeleton; §4.4 and §4.5 walk through the identification and addressing fields; §4.6 covers DataOperation and its consequences; §4.7 treats the inter-document references that bind a stream together; §4.8 assembles everything into a complete, schema-valid example for the Europa Growth Fund. A short pitfalls list and the key takeaways close the chapter.

---

4.2 The Role of ControlData in a Production Flow

Before we look at any field, it is worth asking what a real consumer does with an arriving FundsXML file in its first few milliseconds of existence. The answer turns out to be a short, ordered list, and every item on the list is answered by ControlData. Understanding the list first makes the fields that follow feel obvious rather than arbitrary.

Imagine the classic production setup at a distributor in Paris: an SFTP drop-box that receives FundsXML files from a dozen different asset managers, a dispatcher that triages every arriving file, and a family of downstream processors that each handle a particular kind of content. When a new file lands in the drop-box at 07:03 a.m. CET, the dispatcher does four things, strictly in this order:

1. Recognise. What kind of file is this, and which schema version does it claim to conform to? The root element and its namespace declaration answer both questions; ControlData is inspected immediately afterwards to confirm that the file is a well-structured FundsXML delivery and to read the language of its contents.
2. Authenticate at the business level. Who sent this? The DataSupplier block inside ControlData is compared against an allowlist of approved senders. Transport-level authentication (TLS, SFTP keys) has already happened at this point; the dispatcher is now checking whether the declared sender is one it expects to receive data from.
3. Deduplicate. Have I seen this delivery before? The UniqueDocumentID is looked up in a persistent store of previously processed identifiers. If it is already there, the file is logged and silently discarded; if not, it is recorded and passed on.
4. Sequence. How does this delivery relate to what I already have? DataOperation and the RelatedDocumentIDs references decide whether the file is accepted as new, applied as an update, treated as a correction, or used to retract earlier content.

Figure 4.1 — The first four things a consumer does with a FundsXML file

 Recognise  →  Authenticate  →  Deduplicate  →  Sequence
 ─────────     ────────────     ───────────     ────────
 namespace     DataSupplier     DocumentID      DataOperation
 + schema ref                   lookup          + Related
                                                 Document IDs

Every one of these four steps runs before a single Fund, Portfolio, or RegulatoryReporting element has been read. That is why ControlData is small but disproportionately important: a mistake in the envelope makes the two hundred thousand lines behind it undeliverable.

The rest of this chapter treats the same four steps in the same order. §4.4 fills in Recognise and Deduplicate (document identity and timestamps); §4.5 fills in Authenticate (sender and contact); §4.6 and §4.7 fill in Sequence (data operations and inter-document references). When we assemble the complete example in §4.8, the four steps above are the checklist against which the finished block can be read.

---

4.3 A First Look — Structure and Mandatory Fields

At its heart, a ControlData block is small. Reduced to its mandatory fields only, with generic placeholders in place of real values, it looks like this:

<ControlData>
  <UniqueDocumentID>...</UniqueDocumentID>
  <DocumentGenerated>...</DocumentGenerated>
  <ContentDate>...</ContentDate>
  <DataSupplier>...</DataSupplier>
</ControlData>

Four elements — that is the whole of the mandatory core. Table 4.1 summarises every ControlData field at a glance.

Table 4.1 — ControlData fields at a glance

Field	Required	Type	Purpose
Version	no	string	Schema version the producer built against
UniqueDocumentID	yes	string	Identifies the delivery uniquely in the producer's output stream
DocumentGenerated	yes	dateTime (UTC)	Technical timestamp at which the file was created
ContentDate	yes	date	Business reporting date to which the content refers
DataSupplier	yes	complex	Identifies the business sender of the delivery
DataOperation	no	enumeration	Classifies the delivery: INITIAL, AMEND, DELETE
RelatedDocumentIDs	no	complex	Links the delivery to predecessors it depends on or supersedes
Language	no	ISO 639-1 code	Language of the textual content of the delivery

Several other fields are available but optional, and will appear in the sections that follow. The most important of them are DataOperation, which classifies the delivery as initial, amendment, or deletion; RelatedDocumentIDs, which links the current delivery to the ones it depends on or supersedes; Language, which declares the language of the textual content; and Contact (inside DataSupplier), which records the team or alias to call if the delivery turns out to be broken. §4.5 and §4.7 treat these in turn.

One small but frequent source of confusion is worth mentioning now: the order in which the fields appear inside a real ControlData block is prescribed by the schema, and it is not the didactic order of this chapter. A validator will reject a file in which, for example, ContentDate appears before DocumentGenerated even if every value is correct. We treat the fields in the order that makes them easiest to understand; when we assemble the complete example in §4.8 we will rearrange them into the order the schema expects. The XSD in Appendix C is the authoritative reference for the exact sequence.

---

4.4 Identifying a Delivery — DocumentID, Timestamps, ContentDate

The first three mandatory fields answer the question which delivery is this, and what does it refer to? They look innocuous, but each of them carries a subtle design assumption that, if misunderstood, causes a surprising share of production incidents. We take them one at a time.

4.4.1 UniqueDocumentID — What Makes It Unique

The UniqueDocumentID is a string that identifies this particular FundsXML delivery. The schema places no structural constraint on the string other than that it exists; it is therefore tempting to treat the field as "some kind of identifier, the producer's choice". That reading is technically correct and operationally dangerous.

The guarantee a producer makes when it fills in UniqueDocumentID is stronger than XML validity. It is a promise, to every current and future consumer, that this exact value will never again appear on any other FundsXML delivery coming out of the producer's systems — not tomorrow, not next year, not after a system migration, not after a disaster-recovery restore from a six-month-old backup. The reason the promise matters is step 4 of §4.2: the consumer uses the UniqueDocumentID to recognise duplicates. If the producer reuses an identifier, even once, the consumer's deduplication logic either silently drops a real new delivery (thinking it is a duplicate) or silently accepts two different deliveries as one (corrupting its downstream data).

In practice, there are two sensible strategies.

The first, and the one we recommend as the default, is to use a random UUID — version 4 or the newer version 7. UUIDs are long enough that accidental collisions are astronomically unlikely, and they are trivial to generate in every programming language the fund industry uses. Version 7, which embeds a timestamp in the high bits, has the pleasant side effect that identifiers sort chronologically, which helps when browsing archives.

The second strategy is a semantic identifier constructed from known fields — something like EGF-20260331-INITIAL-001. Semantic identifiers are human-readable and sometimes useful during debugging. They are also fragile: the moment an operational situation demands that the same business day be processed twice (a restarted run, a re-export after a configuration fix), the naïve template collides with itself and the producer must invent an ad-hoc suffix. If you use a semantic scheme, build in a disambiguation suffix from the start — a sequence number, a UUID tail, or a timestamp to millisecond precision. Do not rely on "this can't happen twice".

Why not the filename? A natural shortcut is to reuse the filename of the FundsXML file as its UniqueDocumentID. This is almost always a mistake. Filenames are renamed by transfer agents, case-folded by Windows file systems, rewritten by archive extractors, and silently truncated by legacy pipelines. The UniqueDocumentID is part of the document; it survives every transport. The filename is a property of the envelope around the document; it does not.

The UniqueDocumentID is also not the place to carry human-readable metadata such as the fund name, the reporting date, or the operation type. Those have their own fields. Loading them into the identifier tempts downstream consumers to parse the identifier instead of reading the proper fields — and parsing identifiers across producers is a well-known source of inter-operation bugs.

4.4.2 DocumentGenerated and ContentDate — Two Different Clocks

The most common mistake in ControlData handling is to confuse the two timestamps. The two fields look similar, they occupy adjacent positions in the schema, and under normal circumstances they carry values close to each other. They mean completely different things.

DocumentGenerated is a technical timestamp. It records the moment at which the FundsXML file was produced by the sending system — the point at which the serialiser finished writing bytes to disk or to a network socket. It is the clock that operations, monitoring, and audit pipelines care about. Its type is xs:dateTime, and it is almost always expressed in UTC with a Z suffix.

ContentDate is a business timestamp. It records the reporting date to which the content of the delivery refers — the day whose NAV is being reported, the day on which the portfolio was valued, the day on which the regulatory template is effective. Its type is xs:date (no time component), and it is interpreted in the business calendar of the subject of the delivery, not in the time zone of the producing system.

An example makes the difference concrete. The Europa Growth Fund closes its books for 31 March 2026 at its Luxembourg valuation point (13:00 CET on that same day). The fund administrator's batch job runs overnight and produces the monthly FundsXML delivery at 06:47 UTC on 1 April 2026. The file is placed on the SFTP drop the moment it is finished. The correct ControlData values are:

<ContentDate>2026-03-31</ContentDate>
<DocumentGenerated>2026-04-01T06:47:13Z</DocumentGenerated>

Any other combination is wrong. Setting ContentDate to 2026-04-01 would claim that the content describes 1 April, which is untrue. Setting DocumentGenerated to 2026-03-31T… would lie about when the file came into existence.

A word on time zones. DocumentGenerated should be expressed in UTC. XML Schema allows local time with an offset (2026-04-01T08:47:13+02:00), and the schema accepts such values, but international lieferbeziehungen are better served by the Z convention: it avoids every ambiguity and simplifies comparison across files from different producers. If your system has a strong reason to emit local time with an offset, make sure the offset is correct and constant across daylight-saving transitions, and make sure every consumer you talk to can parse it.

4.4.3 Practical Recipes

The following short recipes cover the four situations that account for almost every real-world ControlData creation.

• Daily NAV, standard business day. ContentDate = today's valuation date. DocumentGenerated = the UTC moment the batch finished. UniqueDocumentID = a fresh UUID.
• Month-end delivery. ContentDate = the last business day of the month (not the first of the next month, and not a calendar month-end that fell on a weekend). DocumentGenerated = whenever the month-end batch actually ran, which may be a day or two later. UniqueDocumentID = a fresh UUID.
• Ad-hoc delivery outside the regular cycle. ContentDate = the business date the content refers to, even if no regular delivery exists for that date. DocumentGenerated = now. UniqueDocumentID = a fresh UUID.
• Backfill for a missed day. ContentDate = the day that was originally missed, possibly weeks in the past. DocumentGenerated = the UTC moment the backfill run finished. UniqueDocumentID = a fresh UUID — it is not the identifier of the original missed delivery, because that delivery never existed. §4.6 covers how backfills interact with DataOperation.

---

4.5 Sender and Contact — DataSupplier

Once a consumer has identified which delivery is on the wire, its next question is who is talking. FundsXML answers this with the mandatory DataSupplier structure, which names the business sender and optionally includes a Contact substructure for escalation.

4.5.1 DataSupplier — Who Is Sending, With What Authority

The DataSupplier block is a small record that describes the business entity responsible for the delivery. Its principal fields are SystemCountry (the ISO country code of the jurisdiction in which the supplier operates), Short (a compact code used for allowlist matching), Name (the full legal or commercial name), Type (an enumeration indicating the supplier's role — asset manager, fund administrator, depositary, and so on), and an optional Contact substructure (telephone or e-mail for incident escalation).

Table 4.2 — DataSupplier fields in practice

Field	Required	Used by consumer for	Typical value
SystemCountry	yes	Jurisdictional context	"LU"
Short	yes	Allowlist matching, compact display	"EAM"
Name	yes	Human display, audit logs	"Europa Asset Management S.A."
Type	yes	Categorisation of sender role	"AssetManager"
Contact	no	Incident escalation (Name, Phone, Email)	email or phone alias

The operational rule that matters more than any other is that a consumer that needs to match a sender against an allowlist matches on the SystemCountry / Short pair, not on the Name. Names change — a corporate rebrand, a merger, a translation of a German legal suffix into its English form — and consumers that match on the name will silently start rejecting valid deliveries after each such change. The SystemCountry / Short pair is stable across most corporate events and is under the producer's control. Any fund-data consumer with more than a handful of counterparties should treat the code pair as the primary key.

It is worth drawing a distinction that causes friction in complex delivery setups: the supplier is not necessarily the party that technically produced the file. A typical arrangement is that an asset manager contracts a fund administrator, who in turn runs the batch that emits the FundsXML document. In this arrangement, DataSupplier usually names the asset manager — the business originator of the content — rather than the administrator, which is merely the technical producer. Consumers authenticate against the asset manager because that is the party they have a contractual relationship with. The administrator's involvement is operational, not declarative. Chapter 13 returns to this distinction when it discusses implementation-project governance; for Chapter 4, the point is simply that "sender" and "producer" can legitimately be different, and ControlData models the sender.

4.5.2 Contact Information

Contact, which appears inside DataSupplier, records a telephone number, an e-mail address, or a team alias that the receiver can use if the delivery is broken and someone needs to be called. The content should be an alias, never an individual: the person who owns the inbox may change, but the alias survives. "fundsxml-support@europa-asset-management.com" is a good contact; "john.smith@europa-asset-management.com" is not.

---

4.6 DataOperation — Thinking Across Deliveries

We now arrive at the conceptual core of the chapter. The previous sections treated each delivery as an isolated object: it has an identity, a date, a sender, a receiver. In reality, every FundsXML delivery is part of a stream — a sequence of deliveries from the same producer to the same consumer, about the same fund, over time. DataOperation is the single field that FundsXML devotes to describing how one delivery relates to the ones that came before it. Six pages, the longest section of the chapter, are devoted to it, because it is also the single most common source of production incidents in FundsXML handling.

4.6.1 Why a Single Delivery Is Never the Whole Story

A live FundsXML interface is not a one-shot exchange. A fund administrator does not send a single file and never another one; it sends a daily NAV file every business day, a monthly portfolio file on the first working day of each month, an occasional correction when a mistake is discovered, and the occasional retraction when a file was emitted in error. Over a year, the same administrator–distributor pair exchanges hundreds of files, all referring to the same handful of funds, all sharing the same DataSupplier, and each of which changes the consumer's state in a specific way. The consumer's job is to reconstruct, at any given moment, the authoritative current picture of each fund — the most recent NAV, the most recent portfolio, the most recent regulatory template — from the accumulated history of deliveries.

FundsXML makes a deliberate decision about who manages that accumulation: not the schema. There is no schema-level notion of a session, a sequence number, a delivery counter, a heartbeat, or a replay acknowledgement. The schema does not tell the producer how often to send, and it does not tell the consumer what to do if a delivery is missing. Everything it provides is one enumerated field — DataOperation — and a set of optional backward references — RelatedDocumentIDs — that §4.7 treats separately.

This minimalism is intentional. FundsXML is a document format, not a workflow protocol. It describes what is in a delivery, not how deliveries are orchestrated. Orchestration — scheduling, retry, acknowledgement, exactly-once handling — lives at the transport and application layers, and is the subject of Chapters 12 and 13. What the schema gives us is a shared vocabulary for saying, about each individual file, what kind of delivery this is. The six pages that follow are about using that vocabulary correctly.

4.6.2 The Three Operation Types

DataOperation is an enumerated field with exactly three values: INITIAL, AMEND, and DELETE. Each value carries a precise semantic meaning that every conforming consumer is expected to implement in the same way. Table 4.3 summarises the three at a glance; the narrative below it explains each in turn.

Table 4.3 — DataOperation semantics at a glance

Operation	Requires a previous delivery?	Consumer action	Typical trigger
INITIAL	no	Replace any existing data for the same subject and ContentDate	First delivery of a new reporting period
AMEND	yes	Modify the previously delivered data (extend, refine, or replace)	Late-arriving data, or a mistake detected after acceptance
DELETE	yes	Retract the previously delivered data as if it had never existed	A delivery was emitted in error

INITIAL marks the beginning of a stream, or the beginning of the data for a particular ContentDate within a stream. When a consumer receives an INITIAL delivery, its expected action is to install the data as the authoritative state for that subject and date, replacing anything it may already hold for the same combination. Repeated INITIAL deliveries for the same ContentDate are permitted and, under the standard's convention, are idempotent: receiving the same INITIAL twice must produce the same end state as receiving it once, provided the content is the same. The deduplication logic of §4.2 exists precisely to let consumers discard the redundant second copy efficiently.

AMEND is FundsXML's single-value umbrella for every non-initial, non-deleting change to an earlier delivery. It covers two operationally distinct but schematically identical cases. The first case is extension: a late-arriving piece of data — a share class whose NAV was delayed by a corporate event, a regulatory template that could not be finalised until the close of a different market — is shipped as an addition to what the consumer already has. The second case is replacement: a figure in a previously delivered file turns out to have been wrong, and the producer ships the corrected value in a new file so that the consumer can overwrite the error. Some older conventions (and some non-FundsXML data standards) distinguish these cases through separate UPDATE and CORRECTION enum values, but FundsXML 4.2.8 folds them into a single AMEND and leaves the semantic distinction to producer-consumer convention. Producers that need to signal which case they are sending typically do so through a text-level marker — a field in CustomAttributes, a tag in the delivery filename, or an out-of-band note to the consumer — rather than through the schema enumeration itself.

The consumer's expected action on receiving an AMEND delivery is to modify its stored state for the referenced subject and ContentDate according to the semantic intent that the producer has signalled. A replacement AMEND overwrites the earlier values; an extension AMEND adds to them. Either way, the RelatedDocumentIDs field (§4.7) should point at the previous delivery in the stream, so that the consumer can chain the changes correctly.

DELETE is the rarest and the most consequential of the three. It tells the consumer to treat a previously delivered document as if it had never existed. The canonical use case is a delivery that should never have been sent — a wrong fund, a wrong date, a draft that was promoted to production by mistake. The consumer's expected action is to remove the affected data from its authoritative state. Because DELETE leaves a hole, it is almost always followed by a corresponding INITIAL or AMEND that restores the intended state. A DELETE that is not followed by a replacement leaves the consumer without data, which is sometimes genuinely what is wanted (a subscription that was never real, a phantom transaction) but more often is a sign that the producer's pipeline is being used defensively when an AMEND would be clearer.

4.6.3 Idempotency and Ordering

Two properties of a consumer's handling of a FundsXML stream matter so much that they deserve to be named explicitly: idempotency and order tolerance.

A consumer is idempotent if processing the same delivery twice produces the same end state as processing it once. Idempotency is not an optional refinement; it is the minimum contract a consumer owes its operational environment, because networks retry, pipelines restart, and drop-boxes occasionally hand the same file to two processing workers. The technical mechanism that makes idempotency achievable is the UniqueDocumentID from §4.4.1: a consumer that records every UniqueDocumentID it has ever successfully processed, and that rejects a second encounter as a duplicate, is idempotent by construction. This is why §4.4.1 spends more words on the identifier than its two lines of XML would seem to deserve.

A consumer is order-tolerant if it behaves correctly when deliveries arrive in an unexpected sequence. The ideal case is that they arrive in the order they were sent; the real case is that networks reorder, queues deliver out of order, and retries of an older file can arrive after a newer one has already been processed. FundsXML does not provide a monotonic sequence number — there is no field whose sole purpose is to say "this delivery is the seventeenth from me". Instead, order is reconstructed after the fact from three signals: ContentDate (which business date does the content refer to?), DocumentGenerated (when was the file physically created?), and RelatedDocumentIDs (which earlier delivery does this one refer to?). A good consumer uses all three: it sorts deliveries for the same subject by ContentDate, breaks ties within a ContentDate by DocumentGenerated, and validates the chain of references with RelatedDocumentIDs.

A short scenario illustrates why this matters. Suppose the producer emits an INITIAL for 31 March 2026 at 07:00 UTC, and ten minutes later emits an AMEND (intended as a correction of an erroneous NAV) for the same date at 07:10 UTC. The two files travel over different network paths, and the AMEND overtakes the INITIAL: the consumer sees the AMEND at 07:11 UTC and the INITIAL at 07:14 UTC. What should the consumer do?

Two strategies are both acceptable, and a well-built pipeline will implement one of them explicitly. The first strategy, buffer and reorder, holds the AMEND aside until its referenced INITIAL has arrived, then applies them in the correct order; this gives the cleanest audit trail. The second strategy, apply and reconcile, applies the AMEND immediately, effectively installing the corrected data on an empty base, and then, when the late INITIAL arrives, refuses to replace the already-corrected state with the older uncorrected data; this is simpler to implement but requires that the consumer's state machine knows the difference between "no data" and "already corrected". Either way, the consumer must not blindly overwrite corrected data with older uncorrected data. The DocumentGenerated timestamp on each delivery is what makes either strategy possible.

4.6.4 Anti-Patterns

The following short list of anti-patterns accounts for the majority of FundsXML production incidents we have seen or heard of. Each item is a rule, followed by its one-line justification.

• Do not send an AMEND before the INITIAL it refers to exists. The consumer has no base on which to apply the change, and will either reject the file or, worse, silently install partial data.
• Do not reuse the same UniqueDocumentID for an INITIAL and a later AMEND. Idempotent deduplication depends on uniqueness; a collision makes the consumer drop the second file as a duplicate even though its content differs.
• Do not send two INITIAL deliveries for the same ContentDate without a clear resolution rule. The consumer does not know which one is authoritative. If the second INITIAL is meant to replace the first, make it an AMEND.
• Do not use DELETE without a follow-up. A DELETE leaves a hole in the consumer's state. If the intent is to correct rather than to retract, use AMEND. If the intent is genuinely to retract, make the retraction explicit in the consumer's audit trail, ideally by following it with an INITIAL that restores the intended state (which may be "no data at all for this date").
• Do not mislabel a replacement AMEND as a silent delta. Because FundsXML collapses extensions and replacements into a single AMEND enum value, the producer must communicate the intent clearly — through a filename convention, a CustomAttributes flag, or an out-of-band note. A consumer that cannot tell a replacement from an extension will either lose data or fail to propagate corrections.

4.6.5 A Small Example Series — ControlData Only

To see the three operations working together, consider four successive ControlData blocks for the same Europa Growth Fund over a four-day period. The rest of the file — Funds, Portfolios, AssetMasterData — is elided, because the payload is the subject of later chapters. Only the envelope is shown.

Day 1, the first delivery of the month-end:

<ControlData>
  <UniqueDocumentID>8a1c0e76-1b7d-4f55-9d2e-11f4a0c8b001</UniqueDocumentID>
  <DocumentGenerated>2026-04-01T06:47:13Z</DocumentGenerated>
  <ContentDate>2026-03-31</ContentDate>
  <DataSupplier>...</DataSupplier>
  <DataOperation>INITIAL</DataOperation>
  <Language>en</Language>
</ControlData>

Day 2, a late-arriving piece of data extends the previous delivery without replacing it:

<ControlData>
  <UniqueDocumentID>8a1c0e76-1b7d-4f55-9d2e-11f4a0c8b002</UniqueDocumentID>
  <DocumentGenerated>2026-04-02T09:12:04Z</DocumentGenerated>
  <ContentDate>2026-03-31</ContentDate>
  <DataSupplier>...</DataSupplier>
  <DataOperation>AMEND</DataOperation>
  <RelatedDocumentIDs>
    <RelatedDocumentID>8a1c0e76-1b7d-4f55-9d2e-11f4a0c8b001</RelatedDocumentID>
  </RelatedDocumentIDs>
  <Language>en</Language>
</ControlData>

Day 3, an NAV that was reported incorrectly on Day 1 is corrected:

<ControlData>
  <UniqueDocumentID>8a1c0e76-1b7d-4f55-9d2e-11f4a0c8b003</UniqueDocumentID>
  <DocumentGenerated>2026-04-03T14:28:50Z</DocumentGenerated>
  <ContentDate>2026-03-31</ContentDate>
  <DataSupplier>...</DataSupplier>
  <DataOperation>AMEND</DataOperation>
  <RelatedDocumentIDs>
    <RelatedDocumentID>8a1c0e76-1b7d-4f55-9d2e-11f4a0c8b002</RelatedDocumentID>
  </RelatedDocumentIDs>
  <Language>en</Language>
</ControlData>

Day 4, the producer discovers that the entire Day 1 delivery was emitted for the wrong fund and retracts it:

<ControlData>
  <UniqueDocumentID>8a1c0e76-1b7d-4f55-9d2e-11f4a0c8b004</UniqueDocumentID>
  <DocumentGenerated>2026-04-04T08:03:22Z</DocumentGenerated>
  <ContentDate>2026-03-31</ContentDate>
  <DataSupplier>...</DataSupplier>
  <DataOperation>DELETE</DataOperation>
  <RelatedDocumentIDs>
    <RelatedDocumentID>8a1c0e76-1b7d-4f55-9d2e-11f4a0c8b003</RelatedDocumentID>
  </RelatedDocumentIDs>
  <Language>en</Language>
</ControlData>

Several observations deserve to be made about this small series. First, every delivery has a new UniqueDocumentID — never a reused one, even though the subject and the ContentDate are the same throughout. Second, every non-INITIAL delivery populates RelatedDocumentIDs to point at the immediately preceding delivery in the stream, not at the INITIAL from Day 1. This is the linear-chain convention that §4.7 recommends: it makes the full history reconstructable by walking the chain backwards, and it avoids the question of what a RelatedDocumentID should mean when it points at a delivery that has itself been superseded. Third, the DataSupplier block is identical across all four deliveries, because the business sender has not changed — only the operational relationship between the deliveries has.

Finally, a meta-observation: most of the complexity in the DataOperation model lives on the consumer side, not on the producer side. A disciplined producer can set DataOperation correctly from a short rule set — "new data for a new date is INITIAL, any change to existing data is AMEND, retraction is DELETE" — and signal the fine distinction between an extension-AMEND and a replacement-AMEND through filename conventions or producer-consumer-specific metadata. A consumer, by contrast, must cope with every legal sequence the producer universe can throw at it, including ones the original producers did not anticipate. When in doubt, err on the side of the consumer: design DataOperation usage to make the consumer's life predictable, not the producer's life convenient.

---

4.7 Versioning and Related Documents

Where §4.6 treated the kind of a delivery, this section treats the links between deliveries. Two topics belong here: the RelatedDocumentIDs element, which binds non-INITIAL deliveries to the ones they depend on, and the schema version declared inside ControlData, which ties every delivery to a specific release of the FundsXML standard.

4.7.1 RelatedDocumentIDs — The Backward Pointer

RelatedDocumentIDs is an optional structure that, when present, lists one or more UniqueDocumentID values referring to earlier deliveries. It appears in the AMEND and DELETE cases shown in §4.6.5 and is conventionally absent from INITIAL deliveries, which by definition do not refer to anything earlier. The schema even makes RelatedDocumentIDs mandatory on a DELETE operation — a DELETE that does not explicitly name the delivery being retracted is not a legal FundsXML file.

Three properties of RelatedDocumentIDs are worth naming explicitly. First, the pointer is backward: an amendment points at the delivery it changes, not the other way round. There is no forward "this-delivery-has-been-superseded-by" pointer in the schema. A consumer that wants to know "is this delivery still authoritative?" must either remember the answer as it processes each new arrival or walk the chain backward from the newest delivery. Second, the pointer is informative, not enforced at the schema level: the XSD does not check that the referenced UniqueDocumentID actually exists, that it belongs to the same subject, or that the referencing operation makes semantic sense against what was referenced. All of that is a business-rule concern, and Chapter 10 treats it in its discussion of two-stage validation. Third, the element is potentially transitive: a second AMEND can refer to the first AMEND, forming a chain, or it can refer directly back to the original INITIAL, skipping the intermediate step. Both conventions are seen in the wild, and neither is forbidden by the schema.

Because both conventions are possible, producers and consumers must agree on one. The convention we recommend — and that Chapter 13 will formalise as a project-level decision — is the linear chain: every non-INITIAL delivery refers to the immediately preceding delivery in the stream, regardless of operation type. The result is a singly-linked list stretching from the newest delivery back to the INITIAL; walking the list backwards always reconstructs the full history, and every intermediate step is explicitly represented. The alternative convention — always pointing at the INITIAL — is simpler to construct but hides intermediate steps and makes it harder to tell whether a replacement AMEND was applied before or after an extension AMEND. Pick one, document it, and stick to it.

One final note: RelatedDocumentIDs is plural because there are cases in which one delivery legitimately depends on more than one predecessor. The most common is a consolidated correction that replaces two or more earlier deliveries at once. These cases are rare enough that most implementations can treat the element as effectively singular, but the plural form is there when it is needed.

4.7.2 Schema Version Handling

A point of practical importance that often surprises first-time FundsXML implementers: the schema file does not declare a targetNamespace. This means instance documents live in the unnamed namespace, and the root element is written without a default namespace declaration. Instead, the root element carries an xsi:noNamespaceSchemaLocation attribute that points directly to the schema file for the version the producer is building against:

<FundsXML4 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:noNamespaceSchemaLocation="https://github.com/fundsxml/schema/releases/download/4.2.2/FundsXML.xsd">

Every released version of the schema is published as a GitHub release under the fundsxml/schema repository. The URL follows a predictable pattern — https://github.com/fundsxml/schema/releases/download/{version}/FundsXML.xsd — where {version} is the release tag (e.g. 4.2.2). This gives every instance document a stable, publicly resolvable reference to the exact schema it was validated against, and it gives any consumer or validator a direct download path to that schema without needing a local copy.

Upgrading to a newer schema version is correspondingly straightforward: the producer updates the version number in the URL. Moving from 4.2.2 to 4.2.5, for example, requires nothing more than changing the root element to:

<FundsXML4 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:noNamespaceSchemaLocation="https://github.com/fundsxml/schema/releases/download/4.2.5/FundsXML.xsd">

All versions of FundsXML since 4.0.0 are designed to be backward compatible, so within the 4.x line such an upgrade is a smooth transition: a consumer built against 4.2.2 will usually accept files produced against 4.2.5, and vice versa. The backwards-compatibility discipline described in §3.3.2 ensures that patch releases add clarifications and non-breaking adjustments, while minor releases add new elements or modules but preserve compatibility for everything that was already present.

In addition to the schema reference in the root element, the schema version is also communicated inside the document, in ControlData/Version. A consumer can inspect this value before running schema validation to confirm which version the producer intended. Recording the version in the audit log alongside the delivery is a discipline worth following: mismatches between producer and consumer schema versions are a recurring source of "it worked yesterday, what changed?" incidents, and the audit log is often the only way to reconstruct what happened.

---

4.8 A Complete ControlData Block for the Europa Growth Fund

We are now ready to assemble the first complete, schema-valid example of the book. The block below is the actual ControlData envelope of the Europa Growth Fund's month-end delivery for 31 March 2026 — the same delivery from which every later chapter of Part II will show a fragment. Field order follows the sequence the schema requires, not the didactic order of this chapter.

<ControlData>
  <UniqueDocumentID>8a1c0e76-1b7d-4f55-9d2e-11f4a0c8b001</UniqueDocumentID>
  <DocumentGenerated>2026-04-01T06:47:13Z</DocumentGenerated>
  <ContentDate>2026-03-31</ContentDate>
  <DataSupplier>
    <SystemCountry>LU</SystemCountry>
    <Short>EAM</Short>
    <Name>Europa Asset Management S.A.</Name>
    <Type>AssetManager</Type>
    <Contact>
      <Email>fundsxml-support@europa-asset-management.com</Email>
    </Contact>
  </DataSupplier>
  <DataOperation>INITIAL</DataOperation>
  <Language>en</Language>
</ControlData>

Reading the block field by field, every design choice from the previous sections becomes visible. The UniqueDocumentID is a UUID, unique across the producer's output stream for the life of the system (§4.4.1). The DocumentGenerated timestamp is expressed in UTC and records the moment the batch job finished writing the file; the ContentDate is a plain date and refers to the business reporting day, which is the last business day of March 2026 (§4.4.2). The DataSupplier block names the fund's asset manager rather than the fund administrator that technically produced the file, and carries the SystemCountry / Short pair that a consumer's allowlist will match against rather than the Name (§4.5.1). The Language is English, which indicates the language of the textual content inside the file — the fund's marketing names and descriptions may still appear in several languages, and Chapter 5 treats that case explicitly. The DataOperation is INITIAL, because this is the first month-end delivery for 31 March 2026; the next delivery in the same stream, whatever it turns out to be, will populate RelatedDocumentIDs to point back at this file's UniqueDocumentID (§4.6, §4.7).

This block is short, and yet every one of the four steps from §4.2 is now answerable from it alone. A consumer that reads these lines and stops has enough information to decide whether to continue parsing the rest of the file, and in production that is exactly what the first stage of a real pipeline does. The complete end-to-end example of the Europa Growth Fund's month-end delivery — this ControlData block plus the Funds, AssetMasterData, Documents, and RegulatoryReportings sections — is printed in Appendix D, and each of the remaining chapters of Part II will take one piece of it for detailed treatment.

---

4.9 Common Pitfalls

The following short list captures the half-dozen mistakes that, in our experience, account for the majority of ControlData-related production incidents. Each entry gives the symptom, the underlying cause, and the fix.

• A new delivery is silently dropped as a duplicate. UniqueDocumentID has been reused, usually because it was generated from a non-unique source such as the filename or a timestamp at second precision. Switch to UUIDs.
• Reports appear for the wrong day. ContentDate has been set to the day the file was produced rather than to the business reporting date. Re-read §4.4.2 and fix the producer's timestamp derivation logic.
• The consumer rejects a known sender as unknown. The allowlist is matching on Name rather than on the SystemCountry / Short pair, and the sender's legal name has just changed (merger, rebrand, translation). Switch the match to the stable code pair.
• An AMEND is rejected because the consumer sees no base state. The AMEND was sent before its INITIAL was successfully processed, or the RelatedDocumentIDs pointer is missing or refers to a non-existent document. Re-issue the INITIAL first, or fix the pointer.
• A correction reaches investors without triggering recalculation. A replacement AMEND was emitted without the producer-consumer convention that distinguishes replacement from extension. The consumer's audit hooks assumed the AMEND was an additive extension rather than a correction and silently installed the new figures without re-issuing affected downstream documents. Agree on a replacement/extension signal between producer and consumer before going live.
• A retracted delivery leaves a hole in the consumer's state. A DELETE was sent without a follow-up INITIAL restoring the intended state. Either send the restoring INITIAL, or confirm explicitly that an empty state is intended and document the gap.

---

4.10 Key Takeaways

• ControlData is the envelope of every FundsXML delivery. It identifies, authenticates, deduplicates, and sequences the file — and all of this happens before any of the fund data behind it is read.
• Four mandatory fields form the core: UniqueDocumentID, DocumentGenerated, ContentDate, and DataSupplier. The optional DataOperation, RelatedDocumentIDs, and Language fields are essential in any production setup.
• DocumentGenerated (technical timestamp) and ContentDate (business reporting date) are two different clocks and must never be confused.
• DataSupplier is matched by its SystemCountry / Short pair, not by Name; an allowlist that matches on the name will silently break on every rebrand or translation.
• DataOperation — INITIAL, AMEND, DELETE — is the only bridge FundsXML provides between successive deliveries. The schema collapses both extensions and replacements into a single AMEND value; the producer-consumer relationship must carry the finer distinction through convention. Idempotency and order tolerance on the consumer side are what make the bridge usable in practice.
• RelatedDocumentIDs carries backward pointers; the recommended convention is a linear chain, in which every non-INITIAL delivery refers to the immediately preceding delivery in the same stream.
• The complete ControlData block in §4.8 is the first schema-valid FundsXML fragment of Part II, and the same values reappear in every subsequent example through to the end of the book.

With the envelope in place, we can now open it and look inside. Chapter 5 turns to the subject of every FundsXML message — the fund itself — and to the static and dynamic data that describe it.

↑ Top

Funds, Sub-Funds, and Share ClassesStatic and dynamic fund information

---

5.1 Setting the Scene: Inside the Envelope

At the end of Chapter 4 we had a ControlData block for the Europa Growth Fund's month-end delivery on 31 March 2026. We knew who had sent it, whom it was meant for, which day it referred to, and that it was the first delivery of its stream. What we did not know was anything about the fund itself. This chapter fills that gap. It is the longest chapter in the book — forty pages — because the Fund element is the element about which everything else in a FundsXML delivery eventually revolves, and because it is also the element where newcomers most often get lost.

Before we begin, one pedagogical decision deserves to be stated up front. The Europa Growth Fund, as we learned in Chapter 1, is a European UCITS equity fund distributed across eleven countries. In reality it has three distinct share classes: a retail euro-denominated accumulating class, a retail Swiss-franc-denominated currency-hedged accumulating class, and an institutional euro-denominated distributing class. Every field we discuss in this chapter exists at one of two levels: either at the level of the fund as a whole, or at the level of an individual share class. The two levels are easy to mix up, and a reader who has to track both at once while also learning about identifiers, classification, and fees is going to struggle.

We therefore take the chapter in four parts. Part I (§5.2 to §5.7) pretends the Europa Growth Fund has exactly one share class and treats every topic as though it lived cleanly on the fund element. Part II (§5.8 to §5.11) relaxes the pretence, puts the three share classes back, and walks through the topics on which the fund-level picture branches. Part III (§5.12 and §5.13) treats the dynamic data — NAVs, total net assets, performance figures — in the light of the share-class structure we have just built. Part IV (§5.14 to §5.17) covers umbrella funds, assembles the complete Fund element, lists the common pitfalls, and summarises the chapter. By the end of Part I the reader should feel comfortable reading a fund's identity; by the end of Part II the reader should be able to talk fluently about share classes; by the end of the chapter the reader should be able to read a complete Fund element on sight and know which of the remaining chapters of Part II of the book each fragment of it belongs to.

By the end of this chapter, you should be able to:

• identify which information in FundsXML belongs to a fund and which belongs to a share class;
• produce and populate every mandatory field of the Fund element for a realistic European UCITS;
• choose the right identifier for every jurisdiction in which a fund is distributed;
• model multilingual fund data without duplicating documents per language;
• distinguish fund-level, share-class-level, and regulatory-level representations of fees and risk indicators;
• read a complete Fund element with multiple share classes on sight and point at the pieces each later chapter of the book treats in depth.

---

5.2 The Fund Element in Context

Inside every FundsXML delivery, immediately after the ControlData envelope, sits a <Funds> container. The container is a simple list: it contains one or more <Fund> elements, each representing a single fund. The list is the schema's way of saying that one delivery may describe more than one fund at a time.

Two production patterns dominate in practice. The first pattern, one fund per file, is the one we have been assuming so far: the Europa Growth Fund is delivered in its own FundsXML file, the <Funds> container holds exactly one <Fund>, and the distributor's dispatcher routes the file by looking at the DataSupplier and the fund's ISIN. This pattern is common when the producer wants fine-grained control over who receives which fund — particularly where distribution agreements vary by country or share class. The second pattern, several funds per file, is more common in fund-administrator batches: a single file carries every fund the administrator serves for a given asset-management client, often several dozen at a time. The container form of <Funds> exists precisely so that the second pattern does not require a wrapper document of its own. Both patterns are valid FundsXML; the choice between them is a pipeline design decision, not a schema decision, and Chapter 12 will come back to it when it discusses integration into system landscapes.

Whichever pattern is used, each <Fund> element has the same shape. Four elements are mandatory and appear at the very top of every <Fund>; the rest follow the separation of static and dynamic data that we named in Chapter 3 as design principle 1, and are wrapped into an optional <SingleFund> container (for non-umbrella funds) or a <Subfunds> container (for umbrella structures, §5.14):

<Fund>
  <Identifiers>
    <!-- LEI of the fund and any other fund-level identifier -->
  </Identifiers>
  <Names>
    <!-- OfficialName, optionally MarketingName, ShortName, LanguageNames -->
  </Names>
  <Currency>EUR</Currency>
  <SingleFundFlag>true</SingleFundFlag>
  <FundStaticData>
    <!-- domicile, legal structure, classifications, benchmarks, ongoing costs, ... -->
  </FundStaticData>
  <FundDynamicData>
    <!-- fund-level total net assets, portfolio, fund-level benchmark values, ... -->
  </FundDynamicData>
  <SingleFund>
    <!-- SingleFundStaticData and the list of ShareClasses -->
  </SingleFund>
</Fund>

The shape deserves two observations. First, Identifiers, Names, Currency, and SingleFundFlag are mandatory and appear before the static/dynamic split. They establish the fund's identity before anything else; a <Fund> element that omits them is not schema-valid. Second, the static/dynamic split is not cosmetic. Many real pipelines ship FundStaticData only when something has changed — perhaps once a month, perhaps only when a new share class is launched or a fee is revised — while shipping a fresh FundDynamicData block every valuation day. Doing so is entirely legal: both FundStaticData and FundDynamicData are optional, a delivery may contain one, the other, or both, and consumers are expected to maintain the last-known state of each half independently. The DataOperation semantics of Chapter 4 apply to whichever half is present.

The <SingleFund> wrapper is where the share-class structure lives. Newcomers often expect <ShareClasses> to hang off FundStaticData, but the schema puts them one level higher: Fund/SingleFund/ShareClasses, as a sibling of the static/dynamic blocks rather than a child of the static one. The reason is that <SingleFund> is one of two alternatives — the other being <Subfunds> for umbrella structures — and making the choice a first-class sibling keeps the two cases symmetric. We take <SingleFund> as the running case for the whole chapter and return to <Subfunds> in §5.14.

Figure 5.1 — Funds as a list

                 <Funds>
                    │
     ┌──────────────┼──────────────┬──────────────┐
     │              │              │              │
  <Fund>         <Fund>         <Fund>         <Fund>
     │              │              │              │
  Static         Static         Static         Static
  Dynamic        Dynamic        Dynamic        Dynamic

Each of the <Fund> boxes is structurally independent of the others: a consumer that cares only about one fund can read that fund and stop without loss of correctness. The AssetMasterData library (Chapter 6) lives outside the <Funds> container, as we saw in Chapter 3, so that instruments shared between several funds in the same delivery can be described once and referenced many times. That cross-fund sharing is the subject of Chapter 6, not this one; Chapter 5 treats each <Fund> as though it were the only fund in the file.

---

5.3 FundStaticData vs FundDynamicData Revisited

Chapter 3 introduced the static/dynamic split as design principle 1. Now that we are about to populate each half, it is worth pausing to ask a more operational question: which field goes where? The principle is intuitive in the limit — a fund's legal name is static, its NAV is dynamic — but the middle is less obvious. Is the launch date of the fund static or dynamic? It never changes, so it sounds static, but many reference systems store it alongside performance data for historical calculations, which makes it feel dynamic. Is the fund's ongoing charges figure static? It is published once a year and does not move between publications, so it is static by default, but a producer that recomputes it on demand at every delivery could reasonably place it in the dynamic half. FundsXML takes a position on each of these questions, and the position is worth understanding because it is the organising principle of every Fund element in the book.

The rule of thumb is straightforward. A field belongs in FundStaticData if, in the ordinary course of operating a fund, it would not need to be re-transmitted to downstream consumers on every valuation day. A field belongs in FundDynamicData if, in the ordinary course of operating a fund, it would. Table 5.1 summarises where the commoner fields land.

Table 5.1 — Where the commoner fields of a fund live

Mandatory header	FundStaticData	FundDynamicData	SingleFund / <ShareClass>
Identifiers/LEI (fund-level)	DomicileCountry	Fund-level TotalAssetValues	Per-class Identifiers (ISIN, GermanWKN, SwissValorenCode)
Names	ListedLegalStructure	Fund-level benchmark values	Per-class Names, Currency, ShareClassType
Currency	InceptionDate (fund)	Portfolio composition (→ Chapter 6)	SubscriptionRestrictions, CurrencyHedgedFlag
SingleFundFlag	FundTexts (strategy, risk, …)		Prices and per-class TotalAssetValues
	Classifications		Fees, Distributions, Flows (→ Chapter 7)
	Benchmarks (static)		PerformanceFigures
	OngoingCosts		HighWatermark, InceptionDate (per class)
	SFDRProductType		RegistrationCountries

Three lines of the table need commentary. Portfolio composition lives inside FundDynamicData/Portfolios — that is the reason the table lists it in the third column — but it is a large enough topic to deserve its own chapter, and this chapter does not treat it. Chapter 6 walks through every asset class and every position-level field. Transactions (subscriptions, redemptions, distributions, corporate actions) live at the share-class level: subscriptions and redemptions under ShareClass/Flows, dividend events under ShareClass/Distributions. They are the subject of Chapter 7. Sections §5.12 and §5.13 of this chapter will cover per-class NAVs, fund-level totals, and performance figures, and will elide portfolio and flow detail when we get there.

A fourth observation is worth stating while the table is in view. Per-class dynamic data lives on each class, not in FundDynamicData. NAV per unit, shares outstanding, per-class total net assets, per-class performance, per-class cash flows and distributions, and per-class portfolios all live inside the individual <ShareClass> element under SingleFund/ShareClasses. FundDynamicData/TotalAssetValues carries a single aggregate figure for the whole fund, and FundDynamicData/Portfolios carries a shared fund-level portfolio where classes are backed by a common asset pool. The split is not always intuitive at first reading; §5.12 returns to it with concrete examples.

The operational consequence of the split is worth stating plainly. In a pipeline designed with static/dynamic separation in mind, the producer's batch job runs in two phases. The first phase, triggered only when something in the fund's identity changes, emits a FundStaticData update — a new share class was launched, a fee was revised, a benchmark was switched. The second phase, triggered on every valuation day, emits a FundDynamicData update — today's NAVs, today's shares outstanding, today's portfolio, today's transactions. The two streams flow through the same FundsXML documents, are sequenced by the same DataOperation mechanics from Chapter 4, and are reconciled by the consumer into a single current-state picture. It is perfectly legal under the schema to ship both halves in every delivery — and many producers do, because the redundancy is cheap and the operational simplification is real. But the ability to split them is available when it matters.

---

5.4 Fund Identifiers — ISIN, WKN, LEI, Valor, and Friends

The first substantive field group of the chapter is the one most likely to trip up a first-time implementer. FundsXML carries several identifiers for each fund, and the reason is that no single identifier universe covers all of the jurisdictions and all of the consumers that European fund data touches. A German investor needs a WKN. A Swiss investor needs a Valor. A regulator needs an LEI. A cross-border distribution agreement is written around ISINs. A legacy Bloomberg terminal may only accept its own proprietary ticker. All of these identifiers coexist, none of them is individually sufficient, and the schema supports all of them at once.

5.4.1 The Hierarchy of Identifiers

Identifiers in FundsXML live at two levels, and both levels use exactly the same container: a <Identifiers> element (of schema type IdentifiersType) that carries a fixed set of named children — ISIN, Bloomberg, CUSIP, GermanWKN, LEI, MexID, ReutersRIC, SEDOL, SwissValorenCode, SwiftBIC — plus a repeatable OtherID escape hatch for everything the schema does not name. One <Identifiers> block sits at the top of the <Fund> element and carries the fund-level identifiers; a separate <Identifiers> block sits at the top of each <ShareClass> element and carries the share-class-level identifiers. The two use the same vocabulary but populate different fields.

Some identifiers — principally the LEI, together with any regulator-issued fund number — identify the fund as a legal entity. These are fund-level identifiers; they exist once per fund and do not care how many share classes the fund has, and they sit inside the fund's own <Identifiers> container. Others — ISIN, GermanWKN, SwissValorenCode, CUSIP, Bloomberg ticker — identify a separately investable unit, which in practice means a single share class. These are share-class-level identifiers; a fund with three share classes has three <Identifiers> blocks, one per class, each populated with the instrument codes of its own class.

For the remainder of Part I we are pretending that the Europa Growth Fund has exactly one share class, so the distinction does not yet matter for narrative purposes: whenever we talk about the fund's ISIN in this part, what we really mean is the ISIN of its only share class. Part II (§5.9) will put the share-class-level identifiers in their proper place inside each <ShareClass>. The only identifier that actually belongs at the fund level is the LEI, and it will remain there throughout. Note that FundsXML uses the name GermanWKN for what German market participants usually call a WKN, and SwissValorenCode for what the Swiss call a Valor. The rest of this chapter uses the short names WKN and Valor in prose and the schema names in XML fragments; readers writing code against the schema should prefer the long forms.

One point deserves to be made now, even before we look at any single identifier in detail: the LEI of the fund is not the LEI of its asset manager. Chapter 4 introduced the LEI of Europa Asset Management S.A. (529900T8BM49AURSDO55) as part of the DataSupplier block. The Europa Growth Fund itself, as a separate legal entity, has its own LEI — 549300ABCDEFGHIJKL34 — and it is this second identifier that appears in Fund/Identifiers/LEI, not the first. Confusing the two is a surprisingly common mistake among producers who have built their pipelines around a single "company LEI" and forgotten that a fund is a legal entity in its own right.

5.4.2 The Core Identifiers in Detail

We take the five most important identifier families in turn. Each entry below gives the structure of the identifier, its issuing body, the level at which FundsXML carries it, and the single most important operational rule associated with it.

ISIN (International Securities Identification Number) is a twelve-character alphanumeric code defined by ISO 6166. The first two characters are the country of issue, the next nine are a national identifier, and the twelfth is a check digit computed by the Luhn-like algorithm of the standard. ISINs are issued by national numbering agencies — in Luxembourg, the Clearstream Banking numbering agency — and are the primary key of cross-border fund distribution in Europe. Every separately investable share class has its own ISIN; a fund with three share classes has three ISINs. At the fund level, strictly speaking, there is no single ISIN — only the collection of its share classes' ISINs — but many producers expose the principal class's ISIN at FundStaticData level as a shortcut for display purposes. The schema tolerates this as long as the same ISIN also appears on its owning share class.

WKN (Wertpapierkennnummer) is a six-character alphanumeric code assigned by the German central numbering agency. It predates the ISIN by several decades and remains mandatory in German fact sheets, German regulator filings, and the displays of German retail broker systems. Every German-distributed share class has a WKN in addition to its ISIN; the two coexist and the same share class carries both. Producers who serve German consumers at any volume populate WKN for every distributed share class automatically.

Valor is a five- to nine-digit numeric code issued by SIX Financial Information in Switzerland. It is the Swiss counterpart to WKN: mandatory for distribution into Switzerland, mandatory for Swiss stock-exchange listings, and expected by every Swiss consumer of fund data. The Europa Growth Fund, which is distributed into Switzerland, carries Valor numbers on its CHF-hedged share class (and often on its EUR classes as well, since Valor can identify any security that a Swiss intermediary may hold on behalf of a client).

LEI (Legal Entity Identifier) is a twenty-character alphanumeric code defined by ISO 17442, issued by local operating units of the Global Legal Entity Identifier Foundation (GLEIF). Unlike ISIN, WKN, and Valor, the LEI identifies a legal entity, not a financial instrument. At the fund level, the LEI uniquely identifies the fund itself; at the umbrella level (which we will come to in §5.14), each sub-fund under the umbrella carries its own LEI and the umbrella carries another. LEIs are required for regulatory reporting under MiFID II, EMIR, AIFMD Annex IV, and SFDR, and producers who forget to populate them will find their deliveries rejected by regulator-facing consumers. Unlike the instrument identifiers, the LEI is also stable across corporate events — a rebranding, a merger, a translation of a legal name — which is why Chapter 4 recommended matching allowlists on LEI rather than on name.

CUSIP (nine-character, North-American) and SEDOL (seven-character, British) appear occasionally on European funds that are marketed to international investors or listed outside Europe. They are less common than the first four, and FundsXML carries them as optional fields when they apply.

Table 5.2 — Fund identifier families

Schema element	Issuer	Level	Typical use
ISIN	National numbering agencies (ISO 6166)	Share class	Cross-border distribution, trading, reference data
GermanWKN	German WM-Datenservice	Share class	German factsheets, retail broker systems, BaFin filings
SwissValorenCode	SIX Financial Information (Switzerland)	Share class	Swiss distribution, SIX Swiss Exchange listings
LEI	GLEIF local operating units	Fund / sub-fund	Regulatory reporting under MiFID II, EMIR, AIFMD, SFDR
CUSIP	CUSIP Global Services (US/Canada)	Share class	Funds marketed to North-American investors
SEDOL	London Stock Exchange (UK)	Share class	British listings and broker systems

5.4.3 OtherID — the Escape Hatch

No schema can enumerate every identifier that every consumer in every jurisdiction will ever need, and FundsXML does not try. For everything that the schema does not define explicitly — internal fund-administrator reference codes, national regulator codes, proprietary distributor identifiers, Morningstar fund IDs — there is the OtherID mechanism. An OtherID element sits inside <Identifiers> alongside the named children, carries a text value, and takes one of two attributes: ListedType, whose value is drawn from a long enumeration of recognised schemes (among them INTERNAL FUND CODE, CSSF FUND CODE, BAFIN ID, AUSTRIAN FUND CODE, CNMV CODE, INAV BLOOMBERG LISTING CODE, REUTERS LISTING CODE, and many others), or FreeType, an open string for schemes the enumeration does not cover. Consumers read the attribute to decide whether they recognise the scheme and, if so, how to interpret the value.

The escape hatch is valuable precisely because it is structured: unlike a generic "extra fields" blob, OtherID forces the producer to declare the scheme of every extra identifier, so that a consumer can decide field by field whether it knows what to do with each one. A typical production <Identifiers> block at the fund level carries the LEI and one or two OtherID entries — the producer's internal fund code under ListedType="INTERNAL FUND CODE", perhaps the national regulator's fund code under ListedType="CSSF FUND CODE" for a Luxembourg fund. For producer-internal reference codes, OtherID ListedType="INTERNAL FUND CODE" is the idiomatic way to transport what some producers historically called a DataSupplierFundID; there is no dedicated element with that name in the schema.

The rule of discipline that matters is that an OtherID must never be used for an identifier that has a dedicated field. Writing the ISIN into an <OtherID ListedType="...">ISIN</OtherID> element instead of into the proper <ISIN> element is a recurring mistake — often the result of a mechanical generator that was configured before the producer learned about the dedicated element — and it breaks downstream consumers who look for ISIN at its expected location. The symptom is a consumer that "cannot find" the ISIN of a fund even though it is right there in the document; the fix is to move the identifier into its proper place and, often, to audit the producer for the same mistake on other fields.

---

5.5 Multilingual Names and Descriptions

Design principle 4 from Chapter 3 — multi-language by design — meets the practicalities of European fund distribution in this section. A single UCITS may be sold in eleven countries under the same ISIN with the same portfolio and the same investment policy, but with eleven different marketing names, eleven translations of its investment objective, and eleven versions of its risk-and-reward narrative. Producing eleven separate FundsXML documents, one per language, would defeat the point of a standard; FundsXML therefore allows every textual field to carry several language variants side by side, so that a single delivery can serve every distribution country at once.

5.5.1 The Names Container and the Language Attribute

FundsXML models fund names through a single <Names> container (schema type NamesType) whose children are named rather than polymorphic. A producer that wants several language variants does not repeat a generic <Name> element with different language attributes at the top of <Names>. Instead, <Names> holds a sequence of specifically named children — OfficialName, FullName, MarketingName, ShortName, PreviousName, DynLenNames, LanguageNames — and only the last of these, LanguageNames, is a repeatable container in which individual <Name> elements each carry a language attribute. The design keeps the single-language fast path simple (one <OfficialName> and done) and concentrates the multilingual machinery in one place.

A complete Europa Growth Fund <Names> block therefore looks like this:

<Names>
  <OfficialName>Europa Asset Management Investments — Europa Growth Sub-Fund</OfficialName>
  <MarketingName>Europa Growth Fund</MarketingName>
  <ShortName>EGF</ShortName>
  <LanguageNames>
    <Name language="de">Europa Wachstumsfonds</Name>
    <Name language="fr">Europa Fonds de Croissance</Name>
    <Name language="it">Europa Fondo di Crescita</Name>
  </LanguageNames>
</Names>

Three things about this block are worth stating explicitly. First, the <OfficialName> is mandatory — every <Names> container must have exactly one, and it is the only element inside <Names> that is required. It carries the fund's primary canonical name in the producer's canonical language, typically the language of the governing jurisdiction. Second, <MarketingName> and <ShortName> are optional fields for the public-facing name and its compact abbreviation; when they are present they apply across languages, because a single marketing name and a single short code are what distributors and broker systems actually display. Third, the language attribute inside <LanguageNames> takes an ISO 639-1 code — en, de, fr, it, es, nl, and so on — and each <Name language="xx"> element carries exactly one translation.

A consumer that needs a localised variant picks the matching LanguageNames/Name; if no variant matches its preferred locale, it falls back to the <MarketingName> (for display purposes), to the <OfficialName> (for legal purposes), or to a configured default language. The fallback discipline is a consumer-side concern; the producer's job is simply to populate as many language variants as the fund's distribution agreements require, and to populate them consistently. Producers should populate all relevant languages in every delivery, not only the language of the intended recipient. A single FundsXML file routed to a French distributor should still carry the German and Italian names alongside the French one, because downstream the distributor may feed the same file into a factsheet engine that renders in any of those languages. Filtering to a single language on the producer side is tempting and wrong.

5.5.2 Types of Names

The children of <Names> come in several shades, and they mean subtly different things. Confusing them is a routine cause of factsheets that display the wrong text.

OfficialName is the fund's full legal name as it appears in the prospectus and in any court or regulatory filing. It is mandatory, and it is the only name that the producer is obliged to populate. For the Europa Growth Fund the official name is Europa Asset Management Investments — Europa Growth Sub-Fund, reflecting the sub-fund relationship even in the standalone-looking listings of this chapter. The official name is typically held in a single canonical language matching the governing jurisdiction; when a jurisdiction requires translations of the legal name, the translations go into LanguageNames alongside the marketing translations.

FullName is an optional longer form that is used in umbrella structures to disambiguate a sub-fund from its umbrella. When a producer prefers to keep OfficialName as just the sub-fund's own name — Europa Growth Sub-Fund — the fully qualified Umbrella SICAV — Europa Growth Sub-Fund form goes into FullName. The two coexist and serve different display contexts.

MarketingName is the marketing or commercial name of the fund — the name that appears on fact sheets, client portals, and advertising. For the Europa Growth Fund this is simply Europa Growth Fund. It is the name the producer wants end-users to see; it is typically shorter and friendlier than the legal name and may differ from it substantially.

ShortName is an abbreviation or short code, used in compact displays such as tables and trading screens. For the Europa Growth Fund it is EGF. The short name is not intended to be multilingual: short codes are typically culturally neutral, and a single string serves all languages.

PreviousName carries the most recent previous name of the fund after a rebranding, along with an @until attribute that names the date on which the previous name ceased to apply. Consumers that maintain historical reference-data joins read the previous name alongside the current one so that older data with the old name can still be matched to the fund.

DynLenNames carries several length-constrained variants of the current name for display systems that truncate at fixed widths — a 16-character short form, a 32-character medium form, a 64-character long form. Producers use it when their consumers include legacy terminals that would otherwise butcher the marketing name. It is optional and rarely populated in modern deliveries.

LanguageNames is the container for translated variants, as we saw in §5.5.1. Each <Name> child inside it carries a two-letter ISO 639-1 language attribute and one translation.

Producer-internal reference codes — what some producers historically called a DataSupplierFundID — do not live inside <Names>. They live inside <Identifiers> as an OtherID entry with ListedType="INTERNAL FUND CODE", as §5.4.3 described. This is worth saying twice because the historical name of the field misled an entire generation of integrators into looking for it in the wrong place.

5.5.3 FundTexts — Investment Objectives, Policies, and Narratives

Longer textual fields — investment objective, investment policy, risk profile narrative, investor profile description — do not live inside <Names>. They live in a separate container, FundStaticData/FundTexts, whose <FundText> children each carry one piece of free-form text alongside its metadata. These are the fields that feed factsheet generators and client-portal descriptions, and their quality determines whether a fund reads like a carefully prepared product or like a machine translation.

Each <FundText> element has the following shape. A <Language> child (mandatory) names the language of the content using an ISO 639 code. A <Date> child (mandatory) names the date on which the text is valid — important because investment-policy wording is revised periodically and consumers need to know which version they are reading. One of <ListedType> or <UnlistedType> (a mandatory choice) names the kind of text: the listed enumeration covers the most common regulated categories — INVESTMENT STRATEGY, INVESTOR PROFILE, RISK DESCRIPTION, RISK MANAGEMENT, FEES, BENCHMARK, SUBS REDS, LEGAL INFORMATION, TAX INFORMATION, ANNUAL REPORT, SEMI ANNUAL REPORT — and <UnlistedType> takes a short free-form label for text categories that the enumeration does not cover. An optional <Title> supplies a display title in the chosen language. A <Content> element (mandatory) carries the text itself. An optional <CountriesWhereApplicable> lists the distribution countries in which this text variant is permitted, for producers that ship jurisdiction-specific wording.

A fund that carries an investment objective in English and German therefore emits two <FundText> elements as siblings inside <FundTexts>, one per language, each with the same <ListedType>INVESTMENT STRATEGY</ListedType> and the same <Date>. A fund that additionally carries a risk description emits further <FundText> elements with <ListedType>RISK DESCRIPTION</ListedType>. A single <FundTexts> block in a realistic delivery typically contains between six and twenty entries, covering the main text categories in the main distribution languages.

Two rules of practice are worth following.

First, the first sentence of <Content> must stand alone. Many downstream consumers — compact fact-sheet templates, distributor search results, one-line product cards — truncate longer descriptions after a fixed number of characters, typically one hundred and fifty to two hundred. A description whose first sentence only makes sense in the context of the second will look mangled in every such consumer. Producers should write the first sentence as a self-contained summary and use the remaining sentences for elaboration.

Second, do not embed HTML or other markup in <Content>. Some consumers escape the markup, some pass it through, and some strip it entirely, and the resulting inconsistency is a well-known source of visible bugs. If a description needs formatting, handle the formatting on the consumer side, or use the root-level <Documents> section (Chapter 9) to deliver a separate rich-text version as a PDF or as structured <BinaryData>.

One interaction is worth noting here for later reference. Chapter 8 treats the FinDatEx regulatory templates (EMT, EPT, EET), and these templates define their own normalised text fields for certain regulated disclosures — the PRIIPs risk narrative, the SFDR sustainability statement, the MiFID target-market description. Where a regulated text field exists, its regulatory version overrides the informal <FundText> entries for the purpose of regulatory consumers, but the informal version continues to serve unregulated consumers such as marketing factsheets. Producers should populate both consistently; consumers should read whichever is appropriate to their use case.

---

5.6 Fund Classification

Every fund in FundsXML carries a set of classification fields that describe what the fund is — in legal, geographic, and investment terms. The classification fields are not the same as the regulatory templates of Chapter 8; they are the fund's own self-description, used by factsheet engines, by distributor search and filter tools, and by internal reference systems. We treat them in three groups: legal form and origin, investment characteristics, and risk-and-benchmark indicators. Almost everything in this section lives inside FundStaticData, at the fund level; registration countries are the one exception and belong to each individual share class (§5.10).

5.6.1 Legal Form, Domicile, and Inception

The first group answers the question where does this fund come from, and under what legal form?

DomicileCountry is the ISO 3166-1 alpha-2 code of the jurisdiction in which the fund is legally domiciled, carried as the very first child of FundStaticData. For the Europa Growth Fund this is LU — Luxembourg, the European fund domicile of choice for cross-border UCITS. The domicile determines which supervisor regulates the fund, which legal form it can take, and which tax regime applies at the fund level.

Registration countries are not a fund-level field. A fund may be domiciled in one country and registered for distribution in several others; in fact, cross-border distribution is the whole point of the UCITS regime. The Europa Growth Fund is domiciled in Luxembourg and registered for distribution in eleven countries: Luxembourg itself, France, Germany, Italy, Spain, the Netherlands, Austria, Belgium, Portugal, Switzerland, and Sweden. A natural first instinct is to model this as a list of CountryOfRegistration children on the fund, but the schema puts the list one level lower: ShareClass/RegistrationCountries/RegistrationCountry, with each entry naming a country code and an operational status (Registered or De-registered). The reason is that two share classes of the same fund may be registered in different countries — the institutional class may be authorised in fewer jurisdictions than the retail class — and a single fund-level list cannot express that. §5.10 returns to this.

Legal structure is expressed through a choice between ListedLegalStructure (an enumerated field covering the common European vehicle types) and UnlistedLegalStructure (a free-text fallback). Both alternatives are declared with minOccurs="0", which means the schema accepts a FundStaticData block that omits the legal structure entirely — producers may do so for funds whose legal nature is carried in country-specific extensions instead. In practice every realistic European fund populates one of the two, and for the Europa Growth Fund we always pick ListedLegalStructure. The enumeration is specific and combines the regulatory regime with the corporate form in single values: UCITS, UCITS - SICAV, UCITS - SICAF, UCITS - CONTRACTUAL TYPE, AIF, AIF - HEDGE FUND, AIF - PRIVATE EQUITY FUND, AIF - VENTURE CAPITAL FUND, AIF - REAL ESTATE FUND, AIF - REIT, AIF - INFRASTRUCTURE FUND, AIF - COMMODITY FUND, AIF - SOVEREIGN WEALTH FUND, AIF - ELTIF, AIF - EUVECA, AIF - EUSEF, and SPV. Because the values already combine regime and corporate form, a producer does not emit two separate entries for UCITS and SICAV: the Europa Growth Fund, which is a UCITS operating as a SICAV, is represented by a single <ListedLegalStructure>UCITS - SICAV</ListedLegalStructure>. The enumeration is the tricky part of this field — producers that try to model the regulatory regime and the corporate form as two independent fields invariably drift away from the schema, and consumers that try to parse the enumerated value into its two halves regret the effort.

InceptionDate, a direct child of FundStaticData, is the date on which the fund first opened for subscription. It is a single xs:date value, and it never changes once the fund is live. The inception date is the anchor for every since-launch performance figure, and consumers that compute annualised returns rely on it. One subtlety deserves an early mention: the fund-level inception date may be earlier than the inception dates of some of the fund's share classes, because share classes can be added to an existing fund long after the fund itself was launched. Every <ShareClass> element therefore also carries its own <InceptionDate>, and Part II (§5.10.3) will treat share-class-level inception in detail.

The schema also carries a handful of adjacent date and status fields that a full FundStaticData block is likely to populate: StartOfFiscalYear and EndOfFiscalYear (as a DayMonthType pair), OpenClosedEnded (OPEN or CLOSED), ClosedType (HARD or SOFT) for funds that have stopped accepting new subscriptions, and MaturityDate/LiquidationDate/LiquidationReason for funds with a planned end. These are all optional, and we do not populate them for the Europa Growth Fund, which is an open-ended UCITS with no fixed maturity and no liquidation date in sight.

5.6.2 Investment Classification via Classifications

The second group of classification fields describes what the fund invests in. Here the schema takes a deliberately indirect approach: instead of defining a single closed vocabulary for asset class, geography, sector, and management style — which would drift out of date every time an industry body published a new taxonomy — FundsXML lets producers declare their classifications in terms of external classification systems. The container is FundStaticData/Classifications, and each child <Classification> carries the source of the classification, its internal type, a language, and one or more values, optionally tagged with a level attribute for hierarchical taxonomies.

The structure of each <Classification> is:

• a choice between <ListedGroup> (a known classification provider, drawn from an enumeration that includes EFAMA, MORNINGSTAR, LIPPER, BLOOMBERG, MIFID, BVI, VOEIG, ESMA, AMF, WM, GERMAN CBCL, CIC, and CFI) and <UnlistedGroup> (a free-text fallback for classifications from bodies the enumeration does not cover);
• an optional <Type> giving the specific taxonomy within the provider (for EFAMA, for example, EFC for the European Fund Classification; for Morningstar, Global Category);
• an optional <Language> attributing the language of the value strings;
• one or more <Value> elements, each with the classification label and an optional level attribute for hierarchies.

The Europa Growth Fund carries two classifications in parallel — one from EFAMA and one from Morningstar:

<Classifications>
  <Classification>
    <ListedGroup>EFAMA</ListedGroup>
    <Type>EFC</Type>
    <Language>en</Language>
    <Value level="1">Equity</Value>
    <Value level="2">Equity Europe</Value>
  </Classification>
  <Classification>
    <ListedGroup>MORNINGSTAR</ListedGroup>
    <Type>Global Category</Type>
    <Language>en</Language>
    <Value>Europe Large-Cap Growth Equity</Value>
  </Classification>
</Classifications>

The advantage of this approach is that it lets each consumer read the classification it recognises. A European distributor that drives its product universe from EFAMA categories reads the EFAMA entry and ignores the Morningstar one; a research analyst whose watchlists are organised by Morningstar category reads the Morningstar entry and ignores the EFAMA one. A consumer that recognises neither can fall back to inspecting OfficialName or Fund/Currency as a last resort, but the Classifications block is what exists for the purpose. The cost is that a reader cannot simply ask "is this an equity fund?" with a single schema-level field: the answer depends on which classification system they read. That trade-off is deliberate, and it reflects the reality of European fund distribution, where no single classification taxonomy has ever achieved the status of the canonical one.

A handful of related flags live one level deeper, under SingleFund/SingleFundStaticData, because they describe the fund as a single (non-umbrella) vehicle: ExchangeTradedFlag, FundOfFundFlag, SocialResponsibleFlag, and — most importantly for classification purposes — ManagementType, which takes the two values ACTIVE and PASSIVE. The Europa Growth Fund is ACTIVE. Producers that want to express finer distinctions such as EnhancedIndex or IndexTracking do so through the Classifications block with an appropriate <ListedGroup> entry.

5.6.3 Risk Indicators and Benchmarks

The third group of classification fields quantifies risk and names the benchmark against which the fund measures itself.

SFDRProductType is a fund-level field inside FundStaticData that names the SFDR (Sustainable Finance Disclosure Regulation) regime under which the fund is classified. It takes integer values 0, 6, 8, or 9: 6 for a fund that qualifies under Article 6 (no sustainability characteristics), 8 for an Article 8 fund (promotes environmental or social characteristics), 9 for an Article 9 fund (has sustainable investment as its objective), and 0 for funds that do not fall under SFDR at all. The Europa Growth Fund is a conventional Article 6 product and therefore carries <SFDRProductType>6</SFDRProductType>. The SFDR classification is the single most consequential ESG-related field in modern European fund disclosure, and consumers that drive ESG product filters read it directly.

The PRIIPs Summary Risk Indicator — the 1-to-7 scale familiar from KIDs and factsheets — does not live at the fund level as a dedicated element in the main schema. The reason is that the SRI is properly a share-class-level figure (different share classes of the same fund can sit at different SRI values, because hedging changes risk characteristics), and the regulated version of the SRI is expressed through the FinDatEx regulatory templates that Chapter 8 treats. Where producers want to carry the SRI alongside FundStaticData for legacy reasons, they do so through CustomAttributes with a name such as SRI and a numeric value. Consumers that need the authoritative SRI read the EMT or the PRIIPs-KID from the <Documents> section.

Benchmark identification lives in FundStaticData/Benchmarks/Benchmark, as a repeatable element whose content follows BenchmarkStaticDataType. Each benchmark entry carries a <BenchmarkID> (an internal key used to link the static description to the dynamic values in FundDynamicData/Benchmarks), a mandatory <Name> and <Currency>, an optional <Provider> (a CompanyType subclass with its own <Identifiers> and <Name>), an optional <BenchmarkType> drawn from an enumeration (Market Index, Blended Benchmark, Custom, Peer Groups and Universes, and others), and an optional <BenchmarkComponents> block for composite benchmarks. The Europa Growth Fund carries a single benchmark entry:

<Benchmarks>
  <Benchmark>
    <BenchmarkID>MSCI-EUR-NR</BenchmarkID>
    <Name>MSCI Europe Net Total Return EUR</Name>
    <Currency>EUR</Currency>
    <Provider>
      <Identifiers>
        <LEI>549300YZUBM5UFHQKY25</LEI>
      </Identifiers>
      <Name>MSCI Limited</Name>
    </Provider>
    <BenchmarkType>Market Index</BenchmarkType>
  </Benchmark>
</Benchmarks>

The <BenchmarkID> is not itself a public identifier — it is a producer-chosen string that a later FundDynamicData/Benchmarks/Benchmark entry will reuse to tie dynamic level data to the static description. The schema enforces this relationship as a key/keyref pair: a dynamic benchmark block whose BenchmarkID does not match a static one is a schema violation, which is the schema's way of preventing a category of reference errors.

A consumer that computes relative performance — alpha, tracking error, information ratio — reads the benchmark's name and currency from the static block and joins against its own market-data source. §5.13 will pick up the dynamic side, where the actual benchmark level on 31 March 2026 is transported inside FundDynamicData/Benchmarks as a <Value> per date.

One forward pointer is worth placing here. Chapter 8 treats the regulatory templates that the fund embeds in the <RegulatoryReportings> root element, and EMT/EPT contain their own versions of the risk indicators, the cost aggregates, and the benchmark references that we are discussing now. Where both layers exist in the same delivery, the regulatory-template version takes precedence for regulatory consumers and the fund-level version serves everyone else. Producers populate both consistently. Consumers read whichever is appropriate to their use case and never try to reconcile one against the other at the millisecond level.

5.6.4 Country-Specific Extensions

A final word on classification: FundsXML is a pan-European standard, but European fund distribution is full of national idiosyncrasies that no single taxonomy can cover gracefully. The schema handles this through CountrySpecificData, an extension container that appears at two levels of a delivery. Inside FundStaticData, a <CountrySpecificData> element carries national reporting extensions that apply to the fund as a whole — Austrian OeNB reporting codes, French AMF sub-classifications, German BVI internal categories, and so on. The national schemas are maintained in separate files (FundsXML4_CountrySpecificData_xx.xsd) that follow the main schema's release cycle. A similar mechanism exists on each individual share class for class-level national extensions. The companion root-level <CountrySpecificData> element, which is a sibling of <Funds> rather than a child, carries country-specific content that is not structurally tied to a single fund. We do not populate CountrySpecificData for the Europa Growth Fund in this chapter — the running example deliberately stays inside the core schema — but producers that serve regulated pipelines in any one European country will almost always end up populating the relevant national extension, and the reader who meets such a block in a real delivery should recognise it as an extension point rather than as data the core schema has somehow mis-named.

---

5.7 Fund-Level Costs and Key Figures

The last section of Part I treats the costs that a fund charges its investors, to the extent that they apply at the fund level rather than at the share-class level. FundsXML splits the cost story into two places. Fund-level aggregate figures — the retrospective per-annum ongoing charges and transaction costs that regulators require on KIDs and factsheets — live in FundStaticData/OngoingCosts. Per-class detailed fees — management fees and other charges that differ between share classes — live inside each <ShareClass> element under Fees/Fee. We introduce the fund-level side here; §5.10 will pick up the per-class side once the share-class structure is in place.

5.7.1 Types of Costs

European fund costs come in several flavours, and the vocabulary has accumulated enough layers over the years that it is worth naming them precisely before we model them.

Management fee is the annual percentage charged by the asset manager for managing the portfolio. It is expressed as a fraction of the fund's net assets and is typically deducted daily in arrears. For a European equity UCITS aimed at retail investors the management fee might be 1.50% per annum; for an institutional class of the same fund it might be 0.75%. Management fees almost always differ between share classes and therefore live on the class.

Administration fee and depositary fee are the charges levied by the fund's administrator and by its custodian bank, respectively. They are often bundled under a single "administration" line in marketing material but are structurally distinct in the fund's cost ledger. They are typically uniform across share classes, and producers can either absorb them into the fund-level ongoing charges figure or carry them as separate fee entries on each class, depending on whether the underlying contracts actually differ between classes.

Performance fee, where it applies, is the share of the fund's out-performance that the asset manager retains as an incentive payment. A typical structure is "20% of out-performance above benchmark, subject to a high watermark, crystallised annually". The three main parameters — rate, hurdle, and the high watermark — together define a complete performance-fee model. FundsXML handles the high watermark explicitly through ShareClass/HighWatermark, and the rate and basis through a fee entry whose Type names the performance fee structure. Producers that omit either the watermark or the fee entry leave consumers unable to reconstruct the actual charge.

TER (Total Expense Ratio) and Ongoing Charges are the retrospective aggregate figures that sum the annual cost of running the fund — management fee, administration, depositary, audit, legal, and every other charge that the fund's investors collectively pay. The two terms are often used interchangeably; strictly speaking, Ongoing Charges (under UCITS KIID and PRIIPs) is slightly narrower than TER (the older EFAMA definition) in that it excludes performance fees, but the numeric values are usually similar. FundsXML carries the value through the OngoingCosts/OngoingCost structure described below, whose <CostType> field names which of the two variants the value represents.

Entry load and exit load, when they apply, are one-time charges levied when an investor buys into or sells out of the fund. They are almost always set at the share-class level — one class of the same fund may charge a 3% entry load while another charges none — and we will return to them in §5.10.

5.7.2 How Fund-Level Costs Are Modelled

The fund-level cost block lives at FundStaticData/OngoingCosts and contains one or more <OngoingCost> children. Each child has a fixed shape: a mandatory <CostType> drawn from a short enumeration (Ongoing Costs, Ongoing Charges, Performance Fee, Transaction Costs), a mandatory <PublicationDate> (the date the figure was computed and published), optional <ValidFrom> and <ValidTo> dates for the period to which the value applies, a mandatory <Percentage> (the value itself, expressed as a decimal percentage — 1.85 means 1.85%, not 0.0185), and an optional <YearlyAmount> for the absolute amount per 10,000 units of investment in the fund's currency. A typical block for a fund whose annual ongoing charges have just been refreshed at the start of the new fiscal year looks like this:

<OngoingCosts>
  <OngoingCost>
    <CostType>Ongoing Charges</CostType>
    <PublicationDate>2025-06-30</PublicationDate>
    <ValidFrom>2025-07-01</ValidFrom>
    <ValidTo>2026-06-30</ValidTo>
    <Percentage>1.85</Percentage>
  </OngoingCost>
</OngoingCosts>

A fund that also discloses a separate transaction-costs figure (common for PRIIPs-KID purposes) would add a second <OngoingCost> entry with <CostType>Transaction Costs</CostType> and its own percentage. The structure is deliberately flat: there is no place for hurdle rates or fee-waiver schedules at this layer, because the layer is designed to carry headline figures that feed factsheets and KIDs, not the full computational machinery behind a fee.

One observation about OngoingCost is worth making explicitly. The Percentage value is given in human-readable percent notation: 1.85 means 1.85 per cent per annum. This matches every other percentage in the schema (type PercentageType), and consumers that treat the value as a fraction (0.0185) will be off by a factor of a hundred — a spectacular error and, unfortunately, a recurring one. The rule of thumb is: if the number in <Percentage> looks like a reasonable management fee when you read it as a percent, it probably is; if it looks like a reasonable management fee after you divide by 100, you are about to make a mistake.

The fund-level block we have just assembled is the producer's own representation of its headline costs — the representation that feeds factsheet engines and distributor search tools. Chapter 8 treats the EMT (European MiFID Template), which defines a different and more detailed representation of the same charges, designed specifically for cost disclosure to retail investors under MiFID II. The EMT version is the definitive one for regulatory purposes; OngoingCosts in FundStaticData is the fund's operational view. Both exist in the same delivery, are populated consistently, and serve different consumers. The per-share-class detailed fee structure — ShareClass/Fees/Fee with its ShareClassFeeType — is the third layer, covered in §5.10, and it is where management fees and any class-specific surcharges actually live.

---

5.8 From One Share Class to Many

So far we have pretended that the Europa Growth Fund has exactly one share class. It does not. It has three, and they are different enough from each other that treating them as one would hide most of what makes real European fund distribution interesting. Part II relaxes the pretence and walks through the topics on which the fund-level picture branches.

The three share classes of the Europa Growth Fund are worth introducing by name, because we will use all three for the rest of the chapter and again in every subsequent chapter of Part II:

• R-EUR-ACC — the retail euro-denominated accumulating share class. Sold to individual investors across the eleven distribution countries, priced in EUR, and thesaurising all income into the NAV rather than paying dividends.
• R-CHF-ACC-HEDGED — the retail Swiss-franc-denominated currency-hedged accumulating share class. Aimed at Swiss retail investors who want exposure to European equities but do not want the EUR/CHF currency risk that would come with holding the ordinary euro class. The portfolio is the same as the R-EUR-ACC class; the difference is a currency overlay that hedges the EUR exposure into CHF.
• I-EUR-DIST — the institutional euro-denominated distributing share class. Aimed at pension funds, insurance companies, and other institutional investors who want predictable income distributions and who qualify for a lower fee schedule because of their minimum investment size.

All three of these share classes belong to the same fund, hold the same portfolio, follow the same investment policy, are managed by the same team, and share the same benchmark. In everything we covered in Part I — legal form, domicile, investment classification, benchmark — they are identical. What differs between them is a specific set of fields that we now need to place inside individual <ShareClass> elements rather than on the fund itself.

The rule that organises the placement is straightforward: anything that differs between share classes lives on the <ShareClass> element; anything that is common to all classes stays on <Fund> and <FundStaticData>. Table 5.3 shows where the main topics land when the rule is applied, using the schema names that actually appear in the XSD.

Table 5.3 — Where the main fields live once share classes are in play

Stays on <Fund> / FundStaticData	Lives inside each <ShareClass>
Fund/Identifiers/LEI (fund LEI)	ShareClass/Identifiers/ISIN, GermanWKN, SwissValorenCode
Fund/Currency (fund base currency)	ShareClass/Currency (class currency)
FundStaticData/DomicileCountry, ListedLegalStructure	ShareClass/RegistrationCountries/RegistrationCountry
FundStaticData/InceptionDate (fund inception)	ShareClass/InceptionDate (class inception)
FundStaticData/FundTexts (investment strategy, risk)	ShareClass/ShareClassType (Code, EarningUse)
FundStaticData/Classifications, Benchmarks	ShareClass/SubscriptionRestrictions/MinSubscriptionAmount
FundStaticData/OngoingCosts (headline costs)	ShareClass/Fees/Fee (per-class management fees, …)
FundStaticData/SFDRProductType	ShareClass/CurrencyHedgedFlag
FundDynamicData/TotalAssetValues (fund aggregate)	ShareClass/Prices/Price (NAV per unit)
FundDynamicData/Portfolios (→ Chapter 6)	ShareClass/TotalAssetValues (class-level TNAV, shares outstanding)
FundDynamicData/Benchmarks (dynamic benchmark values)	ShareClass/PerformanceFigures (per-class returns)
SingleFund/SingleFundStaticData (ManagementType, flags)	ShareClass/Flows, ShareClass/Distributions (→ Chapter 7)

Two consequences of the table deserve to be named explicitly. First, everything from Part I still applies. Share classes do not replace the fund-level fields; they add a new layer of per-class variation. A reader who has understood Part I does not need to unlearn anything in Part II; they just need to learn which of their understood fields now reappear, under schema-correct names, inside <ShareClass>. Second, the portfolio is shared across all share classes. Regardless of how many share classes a fund has, they all ultimately own shares of the same portfolio; the portfolio is a property of the fund, not of its share classes. Chapter 6 walks through the portfolio in detail, and the reader will notice that FundDynamicData/Portfolios hangs off the Fund level rather than off ShareClass. The share classes differ on how claims against the portfolio are structured — what currency the claims are denominated in, what fees they bear, whether they pay out income — but the portfolio itself is singular. (A share class can carry its own ShareClass/Portfolios if the producer reports the portfolio at share-class level, but this is an advanced pattern that the book does not pursue.)

Figure 5.2 — Fund with three share classes

                       <Fund>
        ┌───────┬────────┼─────────┬──────────┐
        │       │        │         │          │
 Identifiers  Names  Currency SingleFundFlag  │
                                              │
          ┌───────────────┬──────────────────┬┘
          │               │                  │
  FundStaticData  FundDynamicData     SingleFund
          │               │                  │
  DomicileCountry  TotalAssetValues    SingleFundStaticData
  LegalStructure   Portfolios (Ch. 6)        │
  InceptionDate    Benchmarks             ShareClasses
  FundTexts                                  │
  Classifications           ┌────────────────┼───────────────────┐
  Benchmarks                │                │                   │
  OngoingCosts       <ShareClass>       <ShareClass>         <ShareClass>
  SFDRProductType     R-EUR-ACC        R-CHF-ACC-HEDGED        I-EUR-DIST
                        ISIN                ISIN                  ISIN
                        EUR, EarningUse=R   CHF, EarningUse=R     EUR, EarningUse=D
                        Min €100            Min CHF 100           Min €1,000,000
                        Mgmt 1.50%          Mgmt 1.50%            Mgmt 0.75%
                        CurrencyHedgedFlag  CurrencyHedgedFlag    CurrencyHedgedFlag
                        =false              =true                 =false
                        Prices, NAVs        Prices, NAVs          Prices, NAVs

The remainder of Part II walks through the topics that the table and the figure put on the share-class side, in an order that mirrors the order of Part I. We begin with identity and currency (§5.9), because those are the topics that differ most visibly. We then treat the behavioural properties that distinguish share classes — earning use, hedging, minimum investment, inception, registration (§5.10). Finally, we look at the patterns that recur across funds and across asset managers when share classes multiply (§5.11), so that the reader leaves Part II with a catalogue of the commoner multi-share-class configurations and can recognise them in the wild.

---

5.9 ShareClass Identity and Currency

5.9.1 Identifiers at the Share Class Level

Each <ShareClass> element begins, just like <Fund>, with an <Identifiers> container. The container is the same schema type (IdentifiersType) as the one at fund level; it accepts the same children; and it is populated with whichever instrument-level codes name the class. ISIN, GermanWKN, SwissValorenCode, CUSIP, SEDOL, and the optional proprietary OtherID entries all live here.

The three share classes of the Europa Growth Fund carry three distinct ISINs:

• R-EUR-ACC — LU2100000011
• R-CHF-ACC-HEDGED — LU2100000029
• I-EUR-DIST — LU2100000037

Each of the three is a twelve-character ISO 6166 identifier; each is issued by the Luxembourg numbering agency (LU prefix); and each refers to exactly one share class. An investor subscribing to the retail euro class buys units whose ISIN is LU2100000011; that investor cannot, by owning units against that ISIN, gain exposure to the CHF-hedged variant without explicitly switching classes. The three ISINs are functionally three different products even though they are backed by the same portfolio.

GermanWKN, SwissValorenCode, CUSIP, and every other share-class-level identifier from §5.4.2 follow the same pattern: one entry per class inside the class's own <Identifiers> block. A German investor who receives a factsheet for the Europa Growth Fund sees three WKNs — one per class — and picks the one that matches the class they want to buy. A Swiss investor sees three Valors. A producer that gets this wrong, and writes a single WKN at the fund level when it should have been three at the class level, will find that German consumers cannot tell the classes apart and routinely route orders to the wrong class.

A rare but real edge case deserves a mention. A share class may, over its lifetime, carry more than one ISIN — for example when two funds merge, and the surviving class inherits the historical ISIN of the disappearing one alongside its own. FundsXML allows this: the class's <Identifiers> can hold a primary <ISIN> together with one or more historical ISINs represented as <OtherID> entries with a descriptive FreeType attribute. Consumers that need historical continuity look at the full set; consumers that need the current identity look only at the <ISIN> field.

Listed share classes — exchange-traded UCITS with public order books — carry additional identification that does not fit neatly into the standard identifier fields. The ticker symbol and the market identifier code (MIC) of the exchange on which the class is listed are carried via ShareClass/MarketPlaces/MarketPlace, which holds a four-character <MarketIdentifierCode>, a <NAVCurrency>, a <TradingCurrency>, and optionally a <MarketMaker> block. Exchange-traded UCITS are described through this block rather than through OtherID, and Chapter 13 returns to the full convention for listed-class metadata.

5.9.2 Currency of the Share Class

Currency is the second field that lives on the class as well as on the fund, and the distinction between class currency and fund base currency is one of the most important conceptual points of this chapter.

The fund base currency is the currency in which the fund's portfolio is primarily denominated and in which the fund's own books are kept. For the Europa Growth Fund this is EUR: the portfolio consists almost entirely of European equities priced in euros, the custody accounts are maintained in euros, and the fund-level total net assets figure is computed in euros. The base currency is a property of the fund, carried in Fund/Currency as a direct child of <Fund> (not inside FundStaticData), and it is one of the four mandatory fund-level elements we saw in §5.2.

The share-class currency is the currency in which the NAV of an individual share class is expressed and in which investors subscribe and redeem against that class. It lives in ShareClass/Currency, the direct counterpart of Fund/Currency, and it may or may not coincide with the base currency. For the Europa Growth Fund's R-EUR-ACC and I-EUR-DIST classes, the class currency is EUR, the same as the base currency; for the R-CHF-ACC-HEDGED class, the class currency is CHF, different from the base currency. All three classes ultimately hold claims against the same EUR-denominated portfolio, but the claims are denominated in different currencies and the claim-holders see different NAV numbers.

The mechanism that makes a CHF class possible when the underlying assets are in EUR is currency hedging. The fund enters into a rolling programme of currency forwards (or another hedging instrument) that converts the EUR exposure into CHF exposure for the purposes of the hedged class. The hedge costs money — interest-rate differentials, forward points, rolling frictions — and the cost is borne by the hedged class alone, which is why its NAV evolves differently from the ordinary euro class even though both classes hold the same underlying portfolio. §5.10 treats hedging as a behavioural property of the class in more detail.

A point of frequent confusion is worth stating plainly: the base currency and the class currency are not interchangeable. A consumer that reads a CHF NAV from an R-CHF-ACC-HEDGED class and treats it as a EUR number will get an answer that is wrong by the EUR/CHF exchange rate — several percent — and that error will propagate through every downstream calculation. The class element always names its own currency explicitly in ShareClass/Currency, and every <Amount> carrying a value in the class's currency has a mandatory ccy attribute that a consumer is expected to read and respect.

---

5.10 Earning Use, Hedging, Subscription, Inception, Registration, Fees

5.10.1 Earning Use: Accumulating and Distributing

The first of the behavioural properties that distinguish share classes is what happens to the income the fund's portfolio generates — dividends on equities, coupons on bonds, interest on cash. The choice is binary: the class either retains the income and reflects it in a higher NAV, or it pays the income out to investors at regular intervals.

Accumulating classes retain income. Every dividend received on the portfolio is added to the fund's net assets; since the share-class's NAV is computed as net assets divided by shares outstanding, and since the number of shares does not change when income is received, the NAV of an accumulating class rises by an amount reflecting the retained income. The investor benefits through capital appreciation of their units rather than through cash in hand. The R-EUR-ACC and R-CHF-ACC-HEDGED classes of the Europa Growth Fund are both accumulating.

Distributing classes pay income out. On a schedule defined in the prospectus — annually, semi-annually, quarterly, or in some cases monthly — the fund declares a dividend, the investors of the distributing class receive a cash payment equal to their pro-rata share of the accumulated income, and the NAV of the class drops on the ex-dividend date by the amount of the distribution. A consumer that renders the NAV of a distributing class over time sees a sawtooth pattern: smooth growth between distributions, a discrete drop on each ex-date. Both the growth and the drop are exactly as they should be — they reflect the same economic reality as the accumulating class's smoother curve, just expressed differently. The I-EUR-DIST class of the Europa Growth Fund is distributing, with an annual ex-date in mid-May each year.

FundsXML models the choice inside ShareClass/ShareClassType, a small structured element (schema type ShareClassTypeType) whose mandatory first child is <Code> — the producer's own class code (e.g. R, I, X, Z) — followed by three optional children: an <EarningUse> enumeration taking one of three single-character values (D for Distributing, P for Partly distributing — the rare hybrid case where some income streams are paid out and others reinvested — and R for Reinvesting, the schema's word for Accumulating), a short <Name> giving a human-readable label, and a longer <Description> text. The Europa Growth Fund's accumulating classes therefore carry <EarningUse>R</EarningUse>, and the distributing institutional class carries <EarningUse>D</EarningUse>. <EarningUse> is schema-optional, so a class whose accumulating-versus-distributing nature is communicated through other fields (e.g. a custom attribute, or implicit from the class code) can omit it; consumers should therefore treat a missing <EarningUse> as "unspecified" rather than as a default. Note the slight terminological mismatch: what the industry calls accumulating is what the schema calls reinvesting (R), because the income is reinvested into the fund rather than paid out. Producers that get the two letters the wrong way round create the single most damaging classification error in the chapter.

The actual dividend events for distributing classes are emitted as Distribution entries inside ShareClass/Distributions. Each <Distribution> has a mandatory <ActionCode> (C/M/D for create/modify/delete), <DividendStatus> (OFFICIAL or ESTIMATED), optional <AnnouncementDate> and <RecordDate>, mandatory <ExDate>, <PaymentDate>, and <PaymentCurrency>, and mandatory <GrossDividendAmount> and <NetDividendAmount> blocks each containing a per-share amount. Chapter 7 treats the flow side in full; the point here is simply that the dividend is not encoded on ShareClassType — the class is flagged D, but the actual events live in a separate time-series.

The consequence for performance comparison is worth naming because it is a routine source of confusion. Two share classes of the same fund, one accumulating and one distributing, have different NAV curves but the same total return — the cumulative performance including reinvested distributions. A consumer that compares raw NAV series between an accumulating and a distributing class will see a divergence that is purely an artefact of distribution treatment; a consumer that compares total returns will see, correctly, that the two classes are economically similar. Chapter 10 treats this as one of the validation rules that a performance-reporting pipeline should enforce.

5.10.2 Currency Hedging

Hedging is the second behavioural property that distinguishes share classes. We described the mechanism briefly in §5.9.2; here we look at how it is represented.

The primary hedging flag is CurrencyHedgedFlag, a Boolean that sits directly inside <ShareClass>. It is true if the class is currency-hedged, false otherwise. The Europa Growth Fund's R-CHF-ACC-HEDGED class has <CurrencyHedgedFlag>true</CurrencyHedgedFlag>, and the other two classes have <CurrencyHedgedFlag>false</CurrencyHedgedFlag> (or simply omit the element). There is no separate HedgedCurrency element: the currency into which the class is hedged is the class currency itself, carried in ShareClass/Currency, so a hedged CHF class naturally has <Currency>CHF</Currency>.

A producer that wants to describe the hedging approach in more detail carries a <FundHedgingStrategy> element either at the fund level (as a child of FundStaticData) or on the individual share class. The element wraps a single <HedgingStrategy> enumeration whose values are No hedge, Full NAV hedge, Full Portfolio hedge, and Partial hedge. A typical retail CHF-hedged share class carries <HedgingStrategy>Full NAV hedge</HedgingStrategy>, meaning that the hedge is calibrated against the class's total net asset value rather than looking through to each underlying currency exposure separately. Full Portfolio hedges are rarer and appear mainly in institutional classes that want their hedge accurate at the instrument level.

One point that routinely surprises newcomers is that the hedge P&L — the profit or loss the class realises from its currency forwards — does not appear as a separate field in FundsXML. It is absorbed silently into the NAV of the hedged class, which is exactly where a disciplined investor expects it to show up: the whole purpose of the hedge is to modify the return pattern of the class, and the NAV is what captures that return. A consumer that wants to decompose the NAV into "portfolio return" and "hedge P&L" separately cannot do so from the FundsXML file alone; the decomposition is a producer-side analytic that is out of scope for the standard.

5.10.3 Subscription Restrictions, Inception, and Registration

The remaining behavioural fields concern the terms under which an investor can buy into the class, the history of the class itself, and the jurisdictions in which the class is authorised for distribution.

Subscription restrictions live in a dedicated <SubscriptionRestrictions> container inside each <ShareClass>. Its main children are:

• MinSubscriptionAmount — the smallest amount a new investor can subscribe to the class in their first transaction, carried as an <Amount ccy="EUR">100</Amount> (or the class's own currency). Retail classes typically set this at a small number — 100 EUR or 1,000 EUR — so that any individual investor can participate. Institutional classes set it much higher — 500,000 EUR, 1,000,000 EUR, 10,000,000 EUR — so that the class is effectively closed to retail participation and can justify its lower fee schedule.
• MinSubscriptionShares — the same restriction expressed in units of the class rather than in currency, for producers that prefer share-count thresholds.
• MinSubscriptionAmountSubsequent and MinSubscriptionSharesSubsequent — the equivalent thresholds for existing investors topping up their positions. They are typically smaller than the initial ones and are rarely zero.
• MinRegularInvestmentAmount and MinRegularInvestmentShares — the thresholds for savings-plan contributions, where a monthly direct-debit subscription has its own minimum.
• OtherSubscriptionRestrictions — a free-text fallback for anything the structured fields do not cover.

For the three share classes of the Europa Growth Fund the thresholds are:

• R-EUR-ACC: MinSubscriptionAmount 100 EUR, MinSubscriptionAmountSubsequent 50 EUR
• R-CHF-ACC-HEDGED: MinSubscriptionAmount 100 CHF (no subsequent minimum declared)
• I-EUR-DIST: MinSubscriptionAmount 1,000,000 EUR (no subsequent minimum declared)

A symmetric <RedemptionRestrictions> container carries the same kind of structure for the sell side — MaxRedemptionAmount, MaxRedemptionShares, MinHoldingPeriod (in months), and OtherRedemptionRestrictions — for classes that apply lock-ups or exit caps.

Investor-type restrictions are not a single flag. The schema carries them through two Booleans on <ShareClass> — <RetailInvestorsOnly> (true for classes that may not be sold to institutional investors, a rarity) and <UK_RDR_Flag> (true for classes that comply with the UK Retail Distribution Review, which bans trailing commissions on retail sales) — and, indirectly, through the minimum-subscription thresholds above. The institutional nature of the Europa Growth Fund's I-EUR-DIST class is communicated through its minimum subscription of 1,000,000 EUR rather than through a dedicated IsInstitutional flag — there is no such field in the schema. Producers that want to make the institutional character explicit can do so by populating ShareClassType/Code with a suggestive value (I) and ShareClassType/Name with a descriptive label (Institutional Distributing). Consumers should never infer investor eligibility purely from a class code — that would re-introduce the name-parsing mistake that §5.11 warns against.

Inception date at the class level lives in ShareClass/InceptionDate and is the date on which the class itself first opened for subscription. It may or may not coincide with the fund-level inception date from §5.6.1. The Europa Growth Fund was launched in 2012; the R-EUR-ACC class has been live since launch and carries <InceptionDate>2012-01-15</InceptionDate>, identical to the fund. The R-CHF-ACC-HEDGED class was added in 2018 to capture Swiss retail demand and carries <InceptionDate>2018-06-01</InceptionDate>. The I-EUR-DIST class was added in 2020 after an institutional anchor investor was secured and carries <InceptionDate>2020-09-15</InceptionDate>.

The distinction between fund inception and class inception matters for performance reporting. The fund's since-launch performance refers to the inception date of the fund and makes sense only for classes that have been live since then. For classes added later, performance from dates prior to class inception does not exist and should not be shown: a since-launch figure for the R-CHF-ACC-HEDGED class starts in June 2018, not in 2012. Consumers that render historical performance are expected to read the class inception date and honour it; producers that emit pre-inception performance are in error, and Chapter 10 will list this among the business-validation rules.

Registration countries at the class level live inside ShareClass/RegistrationCountries/RegistrationCountry. Each entry carries a mandatory <CountryCode> (an ISO 3166-1 alpha-2 code), an optional <Status> (Registered or De-registered), an optional <StatusDate>, an optional <SubStatus> for investor restrictions specific to that jurisdiction (e.g. Institutional Investors only), and an optional <MarketingDistributionStatus> that tracks whether active marketing is currently under way in the country. The retail R-EUR-ACC class of the Europa Growth Fund is registered in all eleven distribution countries; the I-EUR-DIST institutional class is registered in a smaller subset, because institutional distribution is often limited to the jurisdictions in which the producer has an institutional sales team on the ground. Modelling registration per share class rather than per fund is what allows two classes of the same fund to be available in different sets of countries.

5.10.4 Per-Class Fees

The last behavioural topic is the class-specific fee schedule. We introduced the general cost vocabulary in §5.7; here we see how the per-class variant is structured.

Fees that differ between classes live in ShareClass/Fees/Fee, with each <Fee> following the schema type ShareClassFeeType. The mandatory children of a <Fee> are:

• <Type> — a free-text label for the fee, such as Management Fee, Distribution Fee, Entry Load, Performance Fee;
• <PayReceive> — a single character, P for paid by the fund (the usual case) or R for received by the fund (rare);

optionally followed by <Minimum> and <Maximum> as percentages of total net assets, a <CalculationMethod> free-text description, and a <DataByPeriods> container that carries the numeric values per reporting period. Each <DataByPeriod> inside <DataByPeriods> names the period with a <BeginDate> and <EndDate>, optionally a <CurrentDate> for ongoing periods, and a mandatory <Values> block whose key field is <FeeAsPercentageOfTNA> — the percentage of total net assets that the fee represents over the named period. The result is a fee structure that can carry not only the headline rate but also the actual realised rate for every period the producer wants to publish.

A typical management-fee entry on the R-EUR-ACC class of the Europa Growth Fund looks like this:

<Fees>
  <Fee>
    <Type>Management Fee</Type>
    <PayReceive>P</PayReceive>
    <Maximum>1.50</Maximum>
    <CalculationMethod>Per annum of average net assets, accrued daily</CalculationMethod>
    <DataByPeriods>
      <DataByPeriod>
        <BeginDate>2025-07-01</BeginDate>
        <EndDate>2026-06-30</EndDate>
        <CurrentDate>2026-03-31</CurrentDate>
        <Values>
          <FeeAsPercentageOfTNA>1.50</FeeAsPercentageOfTNA>
        </Values>
      </DataByPeriod>
    </DataByPeriods>
  </Fee>
</Fees>

The same structure applies to every per-class fee: a distribution fee, an entry load (where <CalculationMethod> names it as a one-off rather than an annual rate), a performance fee (where <CalculationMethod> would describe the outperformance formula and the crystallisation schedule). For performance fees, the high watermark is carried separately in ShareClass/HighWatermark, whose fields are <ExistingFlag> (Boolean, true if the class has a watermark), <Percentage>, <Amount> (the reference NAV), <Description> (free text), <PeriodicalResetFlag>, and <ResetFrequency>. A full performance-fee specification therefore spans a <Fee> entry and a <HighWatermark> entry, each carrying the part of the story that belongs to it.

One point of confusion that often catches newcomers is the number format of <FeeAsPercentageOfTNA> and <Maximum>. Both use PercentageType, which is human-readable per-cent: 1.50 means 1.50%, not 0.0150. The same rule applies as for OngoingCost/Percentage in §5.7.2: if the number looks like a reasonable fee when read as a percent, it is; if it looks reasonable only after division by a hundred, the producer has emitted the value in the wrong format.

---

5.11 Multi-Share-Class Patterns in Practice

We close Part II with a short catalogue of the patterns that recur in real European fund structures when share classes multiply. The patterns are not defined by FundsXML; they are industry conventions that producers follow and that consumers should recognise. Knowing the patterns makes reading an unfamiliar fund's share-class structure much faster.

5.11.1 Share Class Families and Naming Conventions

The fund industry has evolved a rough alphabet of single-letter codes that mark families of share classes. The conventions vary slightly between asset managers but the common letters are stable enough to be a useful first filter.

• A — retail, often with an entry load of 3–5%
• B — retail, often distributing, and typically carrying the same fee structure as A
• C — retail, with no entry load but a higher management or ongoing-charges figure to compensate
• D — retail, specialised variants (distributing, hedged, clean-priced)
• I — institutional, lower fees, higher minimum investment
• X — super-institutional or omnibus, fees negotiated on a segregated mandate basis
• Z — zero-retrocession, for fee-based advisers who bill their clients directly
• R — retail, modern replacement for A in some post-MiFID-II structures with no entry loads

These letters appear in the fund's marketing material, in factsheets, and in the OfficialName or ShortName fields of the <ShareClass>/Names block, often combined with currency, earning use, and hedging flags: "R-EUR-ACC", "I-USD-DIST-HEDGED", "A-CHF-ACC". The Europa Growth Fund's three classes fit the pattern: R for retail, I for institutional, currencies and earning-use policies spelled out.

One rule is worth stating loudly: the letters are not schema-enforced enumerations, and consumers must not parse them. A class called R-EUR-ACC is retail, euro-denominated, and accumulating not because of its name but because of its Currency, its ShareClassType/EarningUse, its CurrencyHedgedFlag, and its SubscriptionRestrictions/MinSubscriptionAmount fields. A consumer that tries to extract those properties from the name — by string-matching on "R", "EUR", and "ACC" — will eventually meet an asset manager whose naming convention uses different letters, or who combines letters in an order the consumer did not expect, or who simply does not follow a pattern at all. The schema fields exist precisely so that consumers can read the properties authoritatively. Producers populate the names for human eyes; producers populate the fields for machines.

5.11.2 Currency-Hedged Variants

The most common multi-class pattern in cross-border European distribution is a base class paired with one or more currency-hedged variants. The base class holds the fund's native currency (typically EUR for a European fund, USD for a global fund); the hedged variants cover the other major currencies in which the fund is distributed (CHF, GBP, JPY, occasionally SEK or NOK).

Structurally, the base class and its hedged siblings share everything that is a property of the fund — portfolio, investment policy, benchmark, fee schedule, team — and differ only on:

• Identifiers (ISIN, GermanWKN, SwissValorenCode: each variant has its own)
• Currency (EUR on the base, CHF/GBP/JPY/… on each hedged variant)
• CurrencyHedgedFlag (false on the base, true on each hedged variant)
• FundHedgingStrategy (typically No hedge on the base, Full NAV hedge on each hedged variant)
• InceptionDate, if the hedged variants were added later than the base
• NAV and per-class TotalAssetValues, which diverge from the base immediately after inception because of the hedge P&L

Note what does not differ: the per-class fee schedule is typically identical between the base class and its hedged variants, because the hedge cost is absorbed into the NAV rather than charged as a fee. A consumer that wants to identify the hedged siblings of a given class has no direct schema-level mechanism to do so — FundsXML does not define an IsHedgedVariantOf pointer — and has to rely on naming conventions or on producer-supplied metadata in CustomAttributes. Chapter 13 recommends a project-level convention for producers that have several hedged siblings per base class.

5.11.3 Accumulating and Distributing Twins

The second common pattern is a pair of twin classes that share everything except distribution policy: one accumulates income, the other distributes. The pattern is driven by tax treatment — in many jurisdictions, accumulation is more tax-efficient for long-term savers while distribution is preferred by retirees and institutions that need regular cash flow — and by the typical size of the two investor bases.

The twins share portfolio, fee schedule, and currency. They differ on:

• Identifiers (each has its own ISIN, GermanWKN, and so on)
• ShareClassType/EarningUse (R on the accumulating twin, D on the distributing twin)
• Distributions — populated on the distributing twin with the actual dividend events, empty on the accumulating one
• Often InceptionDate (one twin is typically added later than the other)
• NAV and per-class TotalAssetValues, which diverge on the first ex-dividend date and remain divergent thereafter even though total returns are the same

A common trap is to compare the NAVs of twin classes directly over time and conclude that one is outperforming the other. This is almost always an artefact of distribution treatment, not of actual economic divergence. The correct comparison is total return with reinvested distributions, and Chapter 13 will treat this as one of the validation rules that a performance-reporting pipeline should enforce.

5.11.4 When Share Classes Diverge More Deeply

The patterns we have discussed so far — currency variants, accumulating/distributing twins, retail/institutional splits — account for the great majority of real share-class structures. A minority of funds carry classes that differ more deeply: different fee structures, substantially different minimum investments, occasionally even different fee-distribution mechanisms (for example, an adviser class whose distribution commission is built into the NAV versus a clean class whose distribution commission is billed separately to clients). These configurations are all legal and all representable in FundsXML.

What is not legal, and not representable, is a configuration in which two share classes ultimately own different portfolios. The moment two claim groups diverge at the portfolio level, they are no longer two share classes of the same fund — they are two funds, each with its own portfolio. In legal terms this is a sub-fund structure, and it belongs under the umbrella construct that §5.14 treats. Producers occasionally try to model sub-funds as share classes for operational reasons; the result is a FundsXML document that appears internally inconsistent (two share classes, but reconciliation with the shared portfolio impossible) and that fails business validation at the consumer. The rule is straightforward: if the classes share a portfolio, they are share classes; if they do not, they are separate funds or separate sub-funds.

A forward pointer is worth placing here. Chapter 8 treats the EMT regulatory template, and EMT flattens the share-class structure further than FundsXML does: for MiFID cost disclosure purposes, each share class is represented as a separate "product" with its own cost structure, and the underlying fund-level relationships are mostly implicit. The two representations — FundsXML's hierarchical view and EMT's flattened view — serve different consumers and should be populated consistently. Chapter 8 explains how.

---

5.12 Dynamic Data — NAVs, Prices, and Total Net Assets

We now turn to the dynamic half of the <Fund> element. Up to this point we have treated it as "the fields that change every valuation day", which is a correct first approximation, and we have listed the topics it contains. With the share-class structure now in place, we can populate it with meaningful numbers — and, more importantly, we can say clearly where in the XML each figure lives, because the naive expectation that everything dynamic lives inside FundDynamicData is not quite right.

5.12.1 Where Dynamic Data Lives, and What Goes Where

Dynamic fund data is split between three places in the schema.

• FundDynamicData (sibling of FundStaticData under <Fund>) carries only three substructures: TotalAssetValues for fund-level aggregate totals, Portfolios for the shared portfolio composition, and Benchmarks for dynamic benchmark level values. It is deliberately small.
• ShareClass (each class inside SingleFund/ShareClasses) carries almost everything that varies per class: Prices (NAV per unit), TotalAssetValues (per-class aggregate), Distributions (dividend events), Flows (subscriptions and redemptions), PerformanceFigures (returns), and Portfolios if the producer reports the portfolio at share-class rather than fund level.
• SingleFund/SingleFundStaticData carries a handful of flags and classifications that are technically static but describe the single-fund identity (management type, exchange-traded flag, price-published flag).

This chapter treats the dynamic values that matter most to end-users: per-class NAVs (§5.12.2), fund-level totals (§5.12.3), and performance (§5.13). The two substructures we leave alone, Portfolios and Flows / Distributions, are big enough topics to justify chapters of their own: Chapter 6 for portfolio, Chapter 7 for flows and distributions.

5.12.2 NAV and Total Net Assets per Share Class

The net asset value per unit — the NAV that an investor sees in their statement — is the central dynamic figure of any fund. For a fund with multiple share classes, there is no single NAV: there is one NAV per class, and the schema therefore places it on the individual class rather than on the fund as a whole. Each <ShareClass> carries two related substructures.

ShareClass/Prices/Price holds one or more <Price> entries, each of type ShareClassPriceType, carrying the NAV per unit and adjacent price quantities. The mandatory children are <ActionCode> (C/M/D), <NavDate>, <PriceCurrency> (the ISO 4217 code for the class currency), <PriceNature> (OFFICIAL, ESTIMATED, or TECHNICAL), and <NavPrice> (the net asset value per unit, as a decimal with up to 15 total digits and 8 fractional digits). Optional children include <SubscriptionPrice> and <RedemptionPrice> — used when subscription and redemption happen at prices that differ from the mid-NAV, for example because of an entry load or a swing-pricing factor — and <OtherPrices> and <SplitFactor> for less common cases.

ShareClass/TotalAssetValues/TotalAssetValue holds the per-class aggregate: the class's total net asset value and its shares outstanding. The mandatory children are <NavDate> (the valuation date) and <TotalAssetNature> (again OFFICIAL/ESTIMATED/TECHNICAL). The optional but routinely populated children are <TotalNetAssetValue> (a FundAmountType, i.e. a currency-tagged decimal), <TotalGrossAssetValue> (for funds that distinguish the two), <SharesOutstanding> (the number of units of the class outstanding), and <Ratio> (the share of the fund's total net assets that this class represents, as a percentage). A producer that wants to carry alternative valuations — a swing-priced figure, a market-priced figure, a hold-to-maturity figure — adds them in <OtherTotalAssetValues>.

Precision and rounding follow industry convention. NAVs are typically reported to four decimal places (occasionally to eight, as the schema allows); shares outstanding are reported as integers (occasionally to three decimal places for funds that issue fractional shares); total values are reported to two decimal places. A consumer that re-computes NavPrice × SharesOutstanding to verify the producer's total will often find a discrepancy of a cent or two, which is a rounding artefact rather than an error. Chapter 10 treats the tolerance rules that validation pipelines should apply.

The three share classes of the Europa Growth Fund, at the close of 31 March 2026, have the following values:

• R-EUR-ACC: NAV 124.5078 EUR, 1,234,567 shares outstanding, TNAV 153,712,654.83 EUR (ratio 33.09%)
• R-CHF-ACC-HEDGED: NAV 119.2011 CHF, 456,789 shares outstanding, TNAV 54,438,456.22 CHF (ratio 12.21%)
• I-EUR-DIST: NAV 108.3344 EUR, 2,345,678 shares outstanding, TNAV 254,115,322.56 EUR (ratio 54.70%)

In XML form, the NAV and total-asset-value blocks for the R-EUR-ACC class look like this (the other two classes are structurally identical, with their own currencies and amounts):

<ShareClass>
  <!-- Identifiers, Names, Currency, ShareClassType, InceptionDate, … -->
  <Prices>
    <Price>
      <ActionCode>C</ActionCode>
      <NavDate>2026-03-31</NavDate>
      <PriceCurrency>EUR</PriceCurrency>
      <PriceNature>OFFICIAL</PriceNature>
      <NavPrice>124.50780000</NavPrice>
    </Price>
  </Prices>
  <TotalAssetValues>
    <TotalAssetValue>
      <NavDate>2026-03-31</NavDate>
      <TotalAssetNature>OFFICIAL</TotalAssetNature>
      <TotalNetAssetValue>
        <Amount ccy="EUR" isShareClassCcy="true">153712654.83</Amount>
      </TotalNetAssetValue>
      <SharesOutstanding>1234567</SharesOutstanding>
      <Ratio>33.09</Ratio>
    </TotalAssetValue>
  </TotalAssetValues>
  <!-- Fees, Distributions, Flows, PerformanceFigures, … -->
</ShareClass>

Three observations deserve to be made about the block. First, the link to the share class is structural, not nominal. The NAV and the total-asset-value entry are inside the share class's own element; there is no <ShareClassISIN> link of the kind a newcomer might expect, because the ISIN is already the class's own identifier at the top of the class, and a consumer reading the file walks the tree rather than matching by string.

Second, every <Amount> element carries a mandatory ccy attribute that names the currency of the value. The R-CHF-ACC-HEDGED class's NAV is in CHF, not EUR, and the attribute makes this unambiguous — any consumer that ignores it will produce wrong numbers, and Chapter 10 will treat the discipline of always checking currencies as a core validation rule. The isShareClassCcy attribute, a Boolean, is optional but useful: a producer that marks the class-currency amounts with isShareClassCcy="true" tells the consumer explicitly that this value is in the class's own currency, which removes any ambiguity when the same structure is reused in mixed-currency contexts.

Third, the block is self-contained per class. Given only the NAV, the shares outstanding, and the class currency, a consumer can compute every investor-facing value a factsheet needs for that class. The fund-level figures that come next in §5.12.3 are aggregates, not substitutes.

Delivering a daily price history

The examples so far have shown a single <Price> entry for a single valuation date, which is the normal case for a monthly delivery. But the <Prices> container can hold multiple <Price> children, each with its own <NavDate> — and this is exactly what happens when a producer delivers daily NAV history. A transfer agent that sends the complete March 2026 price series for the R-EUR-ACC class, for instance, would populate the container with one entry per business day. The following excerpt shows the first five trading days of the month:

<Prices>
  <Price>
    <ActionCode>C</ActionCode>
    <NavDate>2026-03-02</NavDate>
    <PriceCurrency>EUR</PriceCurrency>
    <PriceNature>OFFICIAL</PriceNature>
    <NavPrice>123.84210000</NavPrice>
  </Price>
  <Price>
    <ActionCode>C</ActionCode>
    <NavDate>2026-03-03</NavDate>
    <PriceCurrency>EUR</PriceCurrency>
    <PriceNature>OFFICIAL</PriceNature>
    <NavPrice>123.96550000</NavPrice>
  </Price>
  <Price>
    <ActionCode>C</ActionCode>
    <NavDate>2026-03-04</NavDate>
    <PriceCurrency>EUR</PriceCurrency>
    <PriceNature>OFFICIAL</PriceNature>
    <NavPrice>124.11030000</NavPrice>
  </Price>
  <Price>
    <ActionCode>C</ActionCode>
    <NavDate>2026-03-05</NavDate>
    <PriceCurrency>EUR</PriceCurrency>
    <PriceNature>OFFICIAL</PriceNature>
    <NavPrice>123.72480000</NavPrice>
  </Price>
  <Price>
    <ActionCode>C</ActionCode>
    <NavDate>2026-03-06</NavDate>
    <PriceCurrency>EUR</PriceCurrency>
    <PriceNature>OFFICIAL</PriceNature>
    <NavPrice>124.00170000</NavPrice>
  </Price>
  <!-- … 17 further business days through 2026-03-31 … -->
</Prices>

Two points are worth noting. First, the order of the <Price> entries within the container is not prescribed by the schema — a consumer must use <NavDate> to sort the series, not the document order. In practice most producers emit entries in chronological order, but a robust consumer does not rely on this. Second, the <PriceCurrency> and <PriceNature> are repeated in every entry, even though they are the same for all days; this is deliberate, because the schema allows a single <Prices> container to carry both an official and an estimated price for the same date, and the currency could in theory change after a redenomination. The repetition keeps each <Price> element self-describing.

5.12.3 Total Net Assets at the Fund Level

Beyond the per-class totals, the fund-level aggregate — the sum of all share-class net assets, expressed in the fund's base currency — lives at FundDynamicData/TotalAssetValues/TotalAssetValue, which reuses the same TotalAssetValueType we just saw but at the enclosing fund level. The per-class figures for the Europa Growth Fund on 31 March 2026 aggregate as follows:

• R-EUR-ACC: 153,712,654.83 EUR
• R-CHF-ACC-HEDGED: 54,438,456.22 CHF, converted at 1 CHF = 1.0420 EUR (the reference rate used by the fund administrator at the valuation point): 56,724,871.39 EUR
• I-EUR-DIST: 254,115,322.56 EUR
• Total: 464,552,848.78 EUR

In XML form, the fund-level aggregate block looks like this:

<FundDynamicData>
  <TotalAssetValues>
    <TotalAssetValue>
      <NavDate>2026-03-31</NavDate>
      <TotalAssetNature>OFFICIAL</TotalAssetNature>
      <TotalNetAssetValue>
        <Amount ccy="EUR" isFundCcy="true">464552848.78</Amount>
      </TotalNetAssetValue>
    </TotalAssetValue>
  </TotalAssetValues>
  <!-- Portfolios (→ Chapter 6), Benchmarks (dynamic values) -->
</FundDynamicData>

The structure is the same one we met at share-class level: the mandatory <NavDate> comes first, then the mandatory <TotalAssetNature>, then the optional <TotalNetAssetValue> with its currency-tagged amount. At fund level the amount carries the isFundCcy="true" attribute to declare it as being in the fund's base currency, which is Fund/Currency (EUR, in our case).

Two points need to be stated clearly. First, the aggregate must respect currency. The CHF total from the R-CHF-ACC-HEDGED class cannot be added directly to the EUR totals from the other two classes; it must first be converted at a reference rate, and the rate used must be consistent with whatever the fund administrator uses internally for the same purpose. A consumer that adds the raw numbers without conversion gets a result that is wrong by several percent and meaningless. Producers should never emit an aggregate that required an implicit currency conversion without being prepared to defend the rate used; consumers should, when reconciling, compute the aggregate from the per-class values themselves to verify.

Second, the fund-level total is the figure that regulatory thresholds hang on. AIFMD size limits, MiFID II cost-disclosure thresholds, national marketing thresholds, and internal concentration limits all use the fund-level TotalNetAssetValue rather than the per-class values. A consumer that implements threshold logic reads the aggregate directly and does not try to re-derive it; if the producer's aggregate disagrees with a reconciliation computation, the discrepancy is a data-quality issue to be raised with the producer, not a licence to pick one figure over the other silently.

---

5.13 Performance and Other Dynamic Figures

5.13.1 Performance Figures per Share Class

Performance — the total return that an investor in a share class has earned over a given period — is the most frequently consulted field in fund data and the one most prone to being reported in inconsistent ways. FundsXML carries performance at the share-class level, inside each <ShareClass> element under ShareClass/PerformanceFigures, with one entry per period per class. The container begins with a mandatory <ActionCode> (C/M/D), then carries three optional sibling lists — <TotalReturns>, <Performances>, and <Ratings> — each of which carries its own flavour of figure. Producers populate whichever combination their downstream consumers expect; none of the three is mandatory, but in practice every monthly delivery populates at least one. We walk through the first two here.

TotalReturns carries one or more <TotalReturn> entries (type TotalReturnType), each describing a total-return value over a specific calculation period, including the effect of reinvested distributions. All four of its core children are mandatory: <Currency>, <Value> (a nested element containing either an <AbsoluteValue> in the currency or a <PercentageValue> — the common case is a percentage), <ValidityDate> (the date at which the return is measured), and <CalculationPeriod> (an enumeration that names the period length). An optional <AnnualizedFlag> marks figures that have been annualised — as a rule, any period of a year or more is reported in annualised form so that three-year and five-year figures are directly comparable. Optional <CalculationMethod>, <Investment>, <StartCalculationDate>, <CorrectionCoefficient>, and <ReinvestmentCoefficient> fields let the producer carry computation provenance alongside the value itself.

The <CalculationPeriod> enumeration names the periods for which total returns are customarily reported:

• 1 Day — one business day (yesterday's return)
• 1 Week — one week
• 1 Month, 3 Months, 6 Months, YTD — one month, three months, six months, year-to-date
• 1 Year, 3 Years, 5 Years, 10 Years — one year, three years, five years, ten years
• Since launch — from the share class's inception date to the current valuation date
• Specific — a custom period whose exact bounds are declared through <StartCalculationDate> and <ValidityDate>

A single entry for the R-EUR-ACC class's one-year return might therefore look like this:

<PerformanceFigures>
  <ActionCode>C</ActionCode>
  <TotalReturns>
    <TotalReturn>
      <Currency>EUR</Currency>
      <Value>
        <PercentageValue>9.4</PercentageValue>
      </Value>
      <ValidityDate>2026-03-31</ValidityDate>
      <CalculationPeriod>1 Year</CalculationPeriod>
    </TotalReturn>
    <TotalReturn>
      <Currency>EUR</Currency>
      <Value>
        <PercentageValue>6.8</PercentageValue>
      </Value>
      <ValidityDate>2026-03-31</ValidityDate>
      <CalculationPeriod>3 Years</CalculationPeriod>
      <AnnualizedFlag>true</AnnualizedFlag>
    </TotalReturn>
  </TotalReturns>
</PerformanceFigures>

Two structural points about this listing. First, the <PercentageValue> is in human-readable per-cent: 9.4 means 9.4%, not 0.094. The convention is the same as for every other percentage in the schema and differs from the fractional form that some numerical libraries default to. Second, the three-year entry carries <AnnualizedFlag>true</AnnualizedFlag>, making explicit that the 6.8% figure is a compound annual growth rate rather than a cumulative three-year return. A consumer that ignores the flag and treats the figure as a cumulative will understate the class's three-year performance by a factor of roughly three.

The Performances container is a near-twin of TotalReturns whose children (type PerformanceType) carry the same kind of information with slightly different shape. Its three mandatory children are <ValidityDate>, <CalculationPeriod>, and <PercentageValue>; optional children include <AnnualizedFlag>, <CalculationMethod>, <StartCalculationDate>, <Investment>, <DateInterval>, and a <DataSeries> block for producers that want to ship the underlying point series alongside the summary figure. In practice producers pick one of the two containers as their primary performance vehicle and use the other rarely; most pipelines we have seen populate TotalReturns.

The net-versus-gross distinction — is this return reported after fees or before them? — is not carried through a dedicated enumerated field in the schema. There is no CalculationBasis enum. Producers who need to transport the distinction do so through the free-text <CalculationMethod> child, using a short convention such as Net of fees, includes reinvested distributions. Consumers should read the <CalculationMethod> on every entry whose interpretation matters to them, and projects whose producers and consumers talk to each other should agree a project-level convention for the calculation-method text. Chapter 10 treats the validation rules that a performance-reporting pipeline should enforce, and Chapter 13 returns to the project-level convention question.

The three share classes of the Europa Growth Fund each carry their own PerformanceFigures block. At the close of 31 March 2026, a representative subset of the values (net of all fees, annualised where applicable) looks like this:

• R-EUR-ACC: 1 Year +9.4%, 3 Years +6.8% annualised, 5 Years +7.1% annualised, Since launch +6.3% annualised
• R-CHF-ACC-HEDGED: 1 Year +8.1%, 3 Years +5.2% annualised, 5 Years +6.0% annualised, Since launch +5.1% annualised
• I-EUR-DIST: 1 Year +10.2%, 3 Years +7.5% annualised, 5 Years +7.8% annualised, Since launch +6.9% annualised

Two patterns are visible in the numbers. First, the R-CHF-ACC-HEDGED class underperforms its base class by roughly one to one and a half percentage points per year, which is the typical order of magnitude for EUR/CHF hedging cost over a multi-year period. Second, the institutional class outperforms the retail class by roughly three-quarters of a percentage point per year, which is approximately the difference in management fees (0.75% for institutional versus 1.50% for retail). Neither pattern is accidental; both are expected consequences of the fee and hedging structure we described in Part II.

5.13.2 Ratings, Watermarks, Listed Prices

Beyond total returns, a handful of smaller dynamic figures deserve mention.

Ratings live in PerformanceFigures/Ratings, where each <Rating> carries a <Note> (the rating value as given by the agency — "5 stars", "AA+", "Silver"), optionally a <NumericalValue>, a <ValidityStartDate> and optional <ValidityEndDate>, and a choice between <ListedAgency> (drawn from an enumeration: FERI, FITCH, MOODYS, MORNINGSTAR, STANDARD-POORS) and <UnlistedAgency> (a CompanyType for other providers). A Morningstar five-star rating for the Europa Growth Fund's R-EUR-ACC class would be carried as <Note>5</Note> with <ListedAgency>MORNINGSTAR</ListedAgency>.

Dividend events for distributing share classes live in ShareClass/Distributions, as we mentioned in §5.10.1. Between ex-dates the class's portfolio continues to generate income; consumers that render client statements on arbitrary dates between distributions compute the accrual themselves from the portfolio income rather than reading a dedicated field, because the schema does not define one. The dividend events are the time-series in Distributions; the current accrual is derived from the portfolio (Chapter 6) and the most recent event.

Bid and ask prices apply to exchange-traded share classes — UCITS that are listed on a public market in addition to, or instead of, being traded through the fund's primary subscription/redemption process. They live inside ShareClass/Prices/Price/OtherPrices, alongside the mid-NAV, and are populated only for listed classes. The ShareClass/MarketPlaces block (§5.9.1) identifies the exchanges on which the class trades; the bid/ask, when needed, sits alongside the NAV in the price block.

High watermarks for share classes that charge a performance fee live in ShareClass/HighWatermark, which we already introduced in §5.10.4. The watermark is the reference NAV above which new performance fees accrue, and is typically reset annually on the fee crystallisation date or, in some structures, only when a drawdown is fully recovered. Consumers that show investors the performance-fee regime display the watermark alongside the current NAV so that the investor can see how close the class is to the next fee accrual.

Every one of these fields is optional. Producers that do not use performance fees omit the high watermark; producers whose classes are not listed omit the bid/ask; producers whose classes carry no external ratings omit the ratings block. The schema is permissive about which fields are populated, and consumers are expected to cope with partial blocks.

---

5.14 Umbrella Funds and Sub-Funds

We close Part IV of the chapter with a variation that we have, until now, deliberately avoided: the umbrella fund structure under which most real European UCITS actually live. Everything we have said about the Europa Growth Fund so far has treated it as a standalone fund — a single legal entity with a single portfolio, a single investment policy, and a set of share classes. In reality, a Luxembourg UCITS of its size would almost always be organised as a sub-fund within an umbrella: a single legal entity called "Europa Asset Management Investments SICAV" (the umbrella), inside which the Europa Growth Fund is one of several sub-funds, each with its own portfolio and each with its own share classes. The umbrella structure is legally efficient — one set of constitutional documents, one board of directors, one regulator — while giving each sub-fund its own investment mandate and its own economic identity.

FundsXML models this structure through the <Subfunds> alternative inside <Fund> that we deferred in §5.2. An umbrella is represented as a single <Fund> element whose <SingleFundFlag> is false and whose <Subfunds> container (instead of <SingleFund>) holds one <Subfund> element per sub-fund. Each <Subfund> is itself a fully-fledged unit — schema type SubfundType — with its own Identifiers, Names, Currency, SubfundStaticData, SubfundDynamicData, and its own ShareClasses list. The umbrella's fund-level <Identifiers>/<LEI> identifies the umbrella SICAV as a legal entity; each <Subfund>/<Identifiers>/<LEI> identifies the individual sub-fund. A consumer that walks the tree can therefore distinguish umbrella and sub-fund at the LEI level without ambiguity.

Two structural consequences deserve to be named. First, the LEI hierarchy doubles: the umbrella has its own LEI on the outer <Fund>, and each sub-fund has its own LEI on its <Subfund>. Regulators that report at the umbrella level read the umbrella LEI; regulators that report at the sub-fund level read the sub-fund LEI. The asset manager, meanwhile, has its own separate LEI from Chapter 4, and the three should never be confused. Second, the share classes operationally attach to the sub-fund: the <ShareClass> elements live inside <Subfund>/<ShareClasses> rather than inside <SingleFund>/<ShareClasses>, but they use the same ShareClassType and the same vocabulary we built up in Part II. For a consumer that already understands the standalone-fund case, the step up to an umbrella is therefore small: read <Subfunds>/<Subfund> instead of <SingleFund> as the container for share classes, and everything below that level is unchanged. This chapter does not build out a complete umbrella example; Chapter 13 returns to the umbrella form in production context when it discusses the operational implications of running a pipeline over a multi-sub-fund SICAV.

For the running example of this chapter we continue to show the Europa Growth Fund as a standalone fund — a <Fund> with <SingleFundFlag>true</SingleFundFlag> and a <SingleFund> child rather than a <Subfunds> child. This is a pedagogical simplification, not a representation of its real legal form. The simplification lets us focus on the share-class structure without also having to explain umbrella mechanics; the complete example in §5.15 is in the standalone form.

---

5.15 The Complete Fund Element for the Europa Growth Fund

We are now ready to assemble the first complete <Fund> element of the book. The listing below combines everything we have treated in Parts I, II, and III of this chapter: the mandatory identity header, the full FundStaticData block with classifications and benchmarks, the FundDynamicData fund-level aggregates, the SingleFund container, and three <ShareClass> entries. To keep the listing readable we show the R-EUR-ACC class in full and collapse the other two classes to their distinguishing fields; portfolio and flow sub-blocks are elided with comments because they belong to Chapters 6 and 7. The complete listing in its fully-populated form appears in Appendix D, and the fragment below has been validated against FundsXML4.xsd end-to-end when embedded in the standard <FundsXML4>/<Funds> envelope.

<Fund>
  <Identifiers>
    <LEI>549300ABCDEFGHIJKL34</LEI>
    <OtherID ListedType="INTERNAL FUND CODE">EAM-EGF-001</OtherID>
  </Identifiers>
  <Names>
    <OfficialName>Europa Asset Management Investments — Europa Growth Sub-Fund</OfficialName>
    <MarketingName>Europa Growth Fund</MarketingName>
    <ShortName>EGF</ShortName>
    <LanguageNames>
      <Name language="de">Europa Wachstumsfonds</Name>
      <Name language="fr">Europa Fonds de Croissance</Name>
    </LanguageNames>
  </Names>
  <Currency>EUR</Currency>
  <SingleFundFlag>true</SingleFundFlag>

  <FundStaticData>
    <DomicileCountry>LU</DomicileCountry>
    <ListedLegalStructure>UCITS - SICAV</ListedLegalStructure>
    <InceptionDate>2012-01-15</InceptionDate>
    <FundTexts>
      <FundText>
        <Language>en</Language>
        <Date>2025-12-31</Date>
        <ListedType>INVESTMENT STRATEGY</ListedType>
        <Title>Investment Objective</Title>
        <Content>The Europa Growth Fund seeks long-term capital appreciation through investment in a diversified portfolio of European equities selected for their growth potential.</Content>
      </FundText>
      <!-- additional FundText entries in de, fr, it ... -->
    </FundTexts>
    <Classifications>
      <Classification>
        <ListedGroup>EFAMA</ListedGroup>
        <Type>EFC</Type>
        <Language>en</Language>
        <Value level="1">Equity</Value>
        <Value level="2">Equity Europe</Value>
      </Classification>
      <Classification>
        <ListedGroup>MORNINGSTAR</ListedGroup>
        <Type>Global Category</Type>
        <Language>en</Language>
        <Value>Europe Large-Cap Growth Equity</Value>
      </Classification>
    </Classifications>
    <Benchmarks>
      <Benchmark>
        <BenchmarkID>MSCI-EUR-NR</BenchmarkID>
        <Name>MSCI Europe Net Total Return EUR</Name>
        <Currency>EUR</Currency>
        <Provider>
          <Identifiers><LEI>549300YZUBM5UFHQKY25</LEI></Identifiers>
          <Name>MSCI Limited</Name>
        </Provider>
        <BenchmarkType>Market Index</BenchmarkType>
      </Benchmark>
    </Benchmarks>
    <FundHedgingStrategy>
      <HedgingStrategy>Full NAV hedge</HedgingStrategy>
    </FundHedgingStrategy>
    <OngoingCosts>
      <OngoingCost>
        <CostType>Ongoing Charges</CostType>
        <PublicationDate>2025-06-30</PublicationDate>
        <ValidFrom>2025-07-01</ValidFrom>
        <ValidTo>2026-06-30</ValidTo>
        <Percentage>1.85</Percentage>
      </OngoingCost>
    </OngoingCosts>
    <SFDRProductType>6</SFDRProductType>
  </FundStaticData>

  <FundDynamicData>
    <TotalAssetValues>
      <TotalAssetValue>
        <NavDate>2026-03-31</NavDate>
        <TotalAssetNature>OFFICIAL</TotalAssetNature>
        <TotalNetAssetValue>
          <Amount ccy="EUR" isFundCcy="true">464552848.78</Amount>
        </TotalNetAssetValue>
      </TotalAssetValue>
    </TotalAssetValues>
    <!-- Portfolios: see Chapter 6. Benchmarks: dynamic level values, elided. -->
  </FundDynamicData>

  <SingleFund>
    <SingleFundStaticData>
      <ExchangeTradedFlag>false</ExchangeTradedFlag>
      <FundOfFundFlag>false</FundOfFundFlag>
      <SocialResponsibleFlag>false</SocialResponsibleFlag>
      <ManagementType>ACTIVE</ManagementType>
      <PricePublishedFlag>true</PricePublishedFlag>
      <SalesCategory>PUBLIC</SalesCategory>
    </SingleFundStaticData>
    <ShareClasses>
      <ShareClass>
        <Identifiers>
          <ISIN>LU2100000011</ISIN>
          <GermanWKN>A2GROW</GermanWKN>
          <SwissValorenCode>54321001</SwissValorenCode>
        </Identifiers>
        <Names>
          <OfficialName>Europa Growth Fund — R EUR ACC</OfficialName>
          <ShortName>EGF R EUR ACC</ShortName>
        </Names>
        <Currency>EUR</Currency>
        <ShareClassType>
          <Code>R</Code>
          <EarningUse>R</EarningUse>
          <Name>Retail Accumulating</Name>
        </ShareClassType>
        <InceptionDate>2012-01-15</InceptionDate>
        <RegistrationCountries>
          <RegistrationCountry><CountryCode>LU</CountryCode><Status>Registered</Status></RegistrationCountry>
          <RegistrationCountry><CountryCode>DE</CountryCode><Status>Registered</Status></RegistrationCountry>
          <RegistrationCountry><CountryCode>FR</CountryCode><Status>Registered</Status></RegistrationCountry>
          <!-- IT, ES, NL, AT, BE, PT, CH, SE elided -->
        </RegistrationCountries>
        <SubscriptionRestrictions>
          <MinSubscriptionAmount>
            <Amount ccy="EUR">100</Amount>
          </MinSubscriptionAmount>
          <MinSubscriptionAmountSubsequent>
            <Amount ccy="EUR">50</Amount>
          </MinSubscriptionAmountSubsequent>
        </SubscriptionRestrictions>
        <OpenToNewInvestorsFlag>true</OpenToNewInvestorsFlag>
        <CurrencyHedgedFlag>false</CurrencyHedgedFlag>
        <IsReferenceShareClass>true</IsReferenceShareClass>
        <IsPublicFlag>true</IsPublicFlag>
        <Prices>
          <Price>
            <ActionCode>C</ActionCode>
            <NavDate>2026-03-31</NavDate>
            <PriceCurrency>EUR</PriceCurrency>
            <PriceNature>OFFICIAL</PriceNature>
            <NavPrice>124.50780000</NavPrice>
          </Price>
        </Prices>
        <TotalAssetValues>
          <TotalAssetValue>
            <NavDate>2026-03-31</NavDate>
            <TotalAssetNature>OFFICIAL</TotalAssetNature>
            <TotalNetAssetValue>
              <Amount ccy="EUR" isShareClassCcy="true">153712654.83</Amount>
            </TotalNetAssetValue>
            <SharesOutstanding>1234567</SharesOutstanding>
            <Ratio>33.09</Ratio>
          </TotalAssetValue>
        </TotalAssetValues>
        <Fees>
          <Fee>
            <Type>Management Fee</Type>
            <PayReceive>P</PayReceive>
            <Maximum>1.50</Maximum>
            <CalculationMethod>Per annum of average net assets, accrued daily</CalculationMethod>
            <DataByPeriods>
              <DataByPeriod>
                <BeginDate>2025-07-01</BeginDate>
                <EndDate>2026-06-30</EndDate>
                <CurrentDate>2026-03-31</CurrentDate>
                <Values><FeeAsPercentageOfTNA>1.50</FeeAsPercentageOfTNA></Values>
              </DataByPeriod>
            </DataByPeriods>
          </Fee>
        </Fees>
        <PerformanceFigures>
          <ActionCode>C</ActionCode>
          <TotalReturns>
            <TotalReturn>
              <Currency>EUR</Currency>
              <Value><PercentageValue>9.4</PercentageValue></Value>
              <ValidityDate>2026-03-31</ValidityDate>
              <CalculationPeriod>1 Year</CalculationPeriod>
            </TotalReturn>
            <TotalReturn>
              <Currency>EUR</Currency>
              <Value><PercentageValue>6.8</PercentageValue></Value>
              <ValidityDate>2026-03-31</ValidityDate>
              <CalculationPeriod>3 Years</CalculationPeriod>
              <AnnualizedFlag>true</AnnualizedFlag>
            </TotalReturn>
          </TotalReturns>
        </PerformanceFigures>
      </ShareClass>

      <ShareClass>
        <Identifiers>
          <ISIN>LU2100000029</ISIN>
          <GermanWKN>A2GRCH</GermanWKN>
          <SwissValorenCode>54321002</SwissValorenCode>
        </Identifiers>
        <Names>
          <OfficialName>Europa Growth Fund — R CHF ACC Hedged</OfficialName>
          <ShortName>EGF R CHF ACC H</ShortName>
        </Names>
        <Currency>CHF</Currency>
        <ShareClassType>
          <Code>R</Code><EarningUse>R</EarningUse>
          <Name>Retail Accumulating, Hedged</Name>
        </ShareClassType>
        <InceptionDate>2018-06-01</InceptionDate>
        <SubscriptionRestrictions>
          <MinSubscriptionAmount><Amount ccy="CHF">100</Amount></MinSubscriptionAmount>
        </SubscriptionRestrictions>
        <CurrencyHedgedFlag>true</CurrencyHedgedFlag>
        <FundHedgingStrategy>
          <HedgingStrategy>Full NAV hedge</HedgingStrategy>
        </FundHedgingStrategy>
        <IsPublicFlag>true</IsPublicFlag>
        <Prices>
          <Price>
            <ActionCode>C</ActionCode>
            <NavDate>2026-03-31</NavDate>
            <PriceCurrency>CHF</PriceCurrency>
            <PriceNature>OFFICIAL</PriceNature>
            <NavPrice>119.20110000</NavPrice>
          </Price>
        </Prices>
        <TotalAssetValues>
          <TotalAssetValue>
            <NavDate>2026-03-31</NavDate>
            <TotalAssetNature>OFFICIAL</TotalAssetNature>
            <TotalNetAssetValue>
              <Amount ccy="CHF" isShareClassCcy="true">54438456.22</Amount>
            </TotalNetAssetValue>
            <SharesOutstanding>456789</SharesOutstanding>
            <Ratio>12.21</Ratio>
          </TotalAssetValue>
        </TotalAssetValues>
        <!-- Fees identical in structure to R-EUR-ACC, elided.
             PerformanceFigures: own series, elided. -->
      </ShareClass>

      <ShareClass>
        <Identifiers>
          <ISIN>LU2100000037</ISIN>
          <GermanWKN>A2GRIN</GermanWKN>
        </Identifiers>
        <Names>
          <OfficialName>Europa Growth Fund — I EUR DIST</OfficialName>
          <ShortName>EGF I EUR DIST</ShortName>
        </Names>
        <Currency>EUR</Currency>
        <ShareClassType>
          <Code>I</Code><EarningUse>D</EarningUse>
          <Name>Institutional Distributing</Name>
        </ShareClassType>
        <InceptionDate>2020-09-15</InceptionDate>
        <SubscriptionRestrictions>
          <MinSubscriptionAmount><Amount ccy="EUR">1000000</Amount></MinSubscriptionAmount>
        </SubscriptionRestrictions>
        <CurrencyHedgedFlag>false</CurrencyHedgedFlag>
        <IsPublicFlag>true</IsPublicFlag>
        <Prices>
          <Price>
            <ActionCode>C</ActionCode>
            <NavDate>2026-03-31</NavDate>
            <PriceCurrency>EUR</PriceCurrency>
            <PriceNature>OFFICIAL</PriceNature>
            <NavPrice>108.33440000</NavPrice>
          </Price>
        </Prices>
        <TotalAssetValues>
          <TotalAssetValue>
            <NavDate>2026-03-31</NavDate>
            <TotalAssetNature>OFFICIAL</TotalAssetNature>
            <TotalNetAssetValue>
              <Amount ccy="EUR" isShareClassCcy="true">254115322.56</Amount>
            </TotalNetAssetValue>
            <SharesOutstanding>2345678</SharesOutstanding>
            <Ratio>54.70</Ratio>
          </TotalAssetValue>
        </TotalAssetValues>
        <Distributions>
          <Distribution>
            <ActionCode>C</ActionCode>
            <DividendStatus>OFFICIAL</DividendStatus>
            <AnnouncementDate>2025-05-02</AnnouncementDate>
            <RecordDate>2025-05-14</RecordDate>
            <ExDate>2025-05-15</ExDate>
            <PaymentDate>2025-05-22</PaymentDate>
            <PaymentCurrency>EUR</PaymentCurrency>
            <GrossDividendAmount>
              <PerShare><Amount ccy="EUR">2.1450</Amount></PerShare>
            </GrossDividendAmount>
            <NetDividendAmount>
              <PerShare><Amount ccy="EUR">1.8450</Amount></PerShare>
            </NetDividendAmount>
          </Distribution>
        </Distributions>
        <!-- Fees: Management Fee 0.75%, same structure as R-EUR-ACC, elided. -->
      </ShareClass>
    </ShareClasses>
  </SingleFund>
</Fund>

Reading the block is best done in three passes, matching the three parts of this chapter.

The first pass looks at the fund's mandatory header and its static data. The <Identifiers> block carries the fund's LEI (549300ABCDEFGHIJKL34), identifying the Europa Growth Fund as a legal entity distinct from the LEI of its asset manager (Chapter 4), together with a producer-internal reference code in an OtherID entry. The <Names> block carries the fund's full official name, its marketing name, a short code, and translations into German and French. The fund's base currency is EUR and the <SingleFundFlag> is true. Inside <FundStaticData> the domicile is Luxembourg; the legal structure is UCITS - SICAV; the fund was launched in 2012; investment-strategy text is carried under <FundTexts>; two parallel <Classifications> entries — EFAMA and Morningstar — describe the fund as a European equity product; a single <Benchmark> names the MSCI Europe Net Total Return EUR index; a single <OngoingCost> entry carries the fund-level headline ongoing charges figure of 1.85% for the current fiscal year; and the <SFDRProductType> is 6, marking the fund as an Article 6 product.

The second pass looks at the share-class structure, carried inside <SingleFund>. The <SingleFundStaticData> block labels the fund as actively managed, not exchange-traded, not a fund of funds, and classified as PUBLIC sales. The three share classes themselves are R-EUR-ACC, R-CHF-ACC-HEDGED, and I-EUR-DIST, each inside its own <ShareClass> element. Each carries its own <Identifiers> block with ISIN and adjacent codes, its own <Names> block, its own <Currency> (EUR or CHF), its own <ShareClassType> with <Code> and <EarningUse> (R for reinvesting, D for distributing), its own <InceptionDate>, and its own subscription minimum. The R-CHF-ACC-HEDGED class is the only one with <CurrencyHedgedFlag>true</CurrencyHedgedFlag>, and it carries a <FundHedgingStrategy>Full NAV hedge</FundHedgingStrategy> at class level in addition. The I-EUR-DIST class is the only one with <EarningUse>D</EarningUse> and is therefore the only one with a populated <Distributions> block — showing the 15 May 2025 dividend event in both its gross and net form.

The third pass looks at the dynamic figures. Each <ShareClass> carries its own <Prices>/<Price> entry — the NAV per unit at 31 March 2026 in the class's own currency — and its own <TotalAssetValues>/<TotalAssetValue> with the mandatory <NavDate> and <TotalAssetNature>, the class's total net asset value (EUR or CHF, marked with isShareClassCcy="true"), the shares outstanding, and a <Ratio> giving the class's share of the fund's total net assets. Alongside the per-class figures, <FundDynamicData>/<TotalAssetValues> carries a single fund-level aggregate entry: 464,552,848.78 EUR, marked with isFundCcy="true" to make clear that the currency is the fund's base currency after conversion of the CHF-denominated class. The <PerformanceFigures> block on R-EUR-ACC shows two total-return entries (one-year and three-year) to illustrate the shape; a fully populated class would carry six to eight entries covering the full set of standard periods.

This <Fund> element is the centrepiece of the Europa Growth Fund's month-end delivery for 31 March 2026, and it will appear — in its complete form, with the portfolio and flows fully populated — in Appendix D. Every subsequent chapter of Part II will take one fragment of the same element for detailed treatment, so that by the time we reach the end of Chapter 9 the reader has seen every part of it explained at least once.

---

5.16 Common Pitfalls

The following short list captures the mistakes that, in our experience, cause the greatest share of fund-element-related production incidents.

• The ISIN is placed on the fund's <Identifiers> instead of on each share class's <Identifiers>. Distributors consuming the delivery fail to distinguish the classes and route subscription orders to whichever class they find first. The fix is to move the ISIN into the <Identifiers> block of each <ShareClass> where it belongs.
• The share-class currency is confused with the fund base currency. A consumer reads 119.2011 from the R-CHF-ACC-HEDGED class and treats it as a EUR number, producing NAV values that are wrong by the EUR/CHF rate. The fix is to respect the ccy attribute on every <Amount> element, and to use the optional isFundCcy / isShareClassCcy attributes as additional self-description.
• A share class is omitted from a delivery. The consumer's current-state engine interprets the absence as a discontinuation and marks the class as closed, leading to factsheet errors and failed order routing. The rule is that every share class must appear in every full delivery even if its data has not changed since the last one.
• The EarningUse code is the wrong letter. The schema uses R for reinvesting (accumulating) and D for distributing; producers occasionally get them the wrong way round because R intuitively looks like retail or return. A class labelled <EarningUse>R</EarningUse> when it should be D causes every distributing-class consumer to misclassify the fund. The fix is to verify the letter on every class against the class's prospectus behaviour.
• Performance figures are emitted without a calculation-method annotation. The schema does not carry a net/gross flag as a structured field; the distinction rides in the free-text <CalculationMethod> child of <TotalReturn>. One downstream consumer treats the figures as net, another as gross, and the two disagree about how the fund is performing. The fix is to populate a short, project-stable calculation-method string on every entry and to document the convention at project level.
• The inception date is inherited from the fund rather than set per share class. A since-launch performance figure for the R-CHF-ACC-HEDGED class starts in 2012 (fund inception) rather than 2018 (class inception), showing six years of performance that the class did not experience. The fix is to populate <InceptionDate> inside each <ShareClass> and compute performance from there.
• A consumer parses the share-class name to infer currency and earning use. The consumer's logic breaks when it meets an asset manager whose naming convention differs. The fix is to read ShareClass/Currency, ShareClass/ShareClassType/EarningUse, ShareClass/CurrencyHedgedFlag, and ShareClass/SubscriptionRestrictions/MinSubscriptionAmount as structured fields and never depend on the name.
• The fund-level <Classifications> block is used to transport ad-hoc strings rather than recognised classification systems. A producer writes <ListedGroup>EFAMA</ListedGroup> but populates <Value> with a home-grown label that the EFAMA taxonomy does not use. Consumers that recognise EFAMA then mismatch. The fix is to populate each <Classification> with values from the taxonomy its <ListedGroup> names, and to use <UnlistedGroup> when the classification is proprietary.

---

5.17 Key Takeaways

• A FundsXML document may contain one or several <Fund> elements. Each <Fund> begins with four mandatory children — Identifiers, Names, Currency, SingleFundFlag — and then optionally carries FundStaticData, FundDynamicData, and a choice of SingleFund (for non-umbrella funds) or Subfunds (for umbrella structures). Share classes live inside SingleFund/ShareClasses, not inside FundStaticData.
• Fund identifiers live at two levels, both using the same IdentifiersType container. Fund/Identifiers carries fund-level codes (principally LEI); each ShareClass/Identifiers carries share-class-level codes (ISIN, GermanWKN, SwissValorenCode, CUSIP, SEDOL, and proprietary OtherID entries). Confusing the levels is the commonest structural mistake in the fund element.
• Names are modelled through the NamesType container with a mandatory <OfficialName>, optional <MarketingName>, <ShortName>, <FullName>, <PreviousName>, and a <LanguageNames> child that holds the multilingual translations as <Name language="xx"> entries. Longer narrative text lives in FundStaticData/FundTexts, with a <ListedType> that names the kind of text and a free-form <Content>.
• Fund classification — domicile, legal structure, inception date, investment classification, benchmark, SFDR product type — lives in FundStaticData. Investment classification is expressed through Classifications/Classification entries that reference external taxonomies (EFAMA, Morningstar, MiFID, and others) rather than a single closed vocabulary. The regulatory templates in Chapter 8 provide richer versions of the same information for regulated use cases.
• Share classes are the structural branch of the fund element. Fields that differ between classes — identifiers, Currency, ShareClassType/EarningUse, CurrencyHedgedFlag, SubscriptionRestrictions, per-class Fees, InceptionDate, Prices, TotalAssetValues, PerformanceFigures, RegistrationCountries — live on the individual <ShareClass> element. Everything common to all classes stays on <Fund> or in FundStaticData.
• Fees are modelled at three layers. FundStaticData/OngoingCosts carries headline fund-level aggregate figures (TER, ongoing charges, transaction costs, performance fees) with <Percentage> in human-readable per-cent. ShareClass/Fees/Fee carries per-class management and distribution fees with mandatory Type and PayReceive, optional Minimum/Maximum/CalculationMethod, and DataByPeriods/DataByPeriod/Values/FeeAsPercentageOfTNA for the period values. ShareClass/HighWatermark carries the high-watermark reference for performance-fee classes.
• Per-class dynamic data lives inside each <ShareClass>: Prices for the NAV per unit, TotalAssetValues for the class aggregate with shares outstanding and ratio, Distributions for dividend events, Flows for subscriptions and redemptions, PerformanceFigures for total returns and ratings. FundDynamicData/TotalAssetValues carries only the single fund-level aggregate; consumers that need per-class dynamic figures read them from the classes themselves.
• Performance is carried in ShareClass/PerformanceFigures with <TotalReturn> entries that name their calculation period through a <CalculationPeriod> enumeration (1 Day, 1 Month, YTD, 1 Year, 3 Years, Since launch, Specific) and carry their value as either <AbsoluteValue> or <PercentageValue>. The net-versus-gross distinction rides in free-text <CalculationMethod>; there is no dedicated enum for it in the schema.
• Umbrella funds are modelled through the <Subfunds>/<Subfund> alternative inside <Fund>, with each sub-fund carrying its own Identifiers, Names, Currency, SubfundStaticData, SubfundDynamicData, and ShareClasses. The running example in §5.15 is shown in the standalone <SingleFund> form for pedagogical clarity; Chapter 13 treats the umbrella form in production context.

We have now described the Europa Growth Fund: what it is, how its share classes differ, and what its NAVs look like on 31 March 2026. What we have not yet seen is what the fund actually holds. Chapter 6 opens the Portfolios substructure of FundDynamicData and walks, asset class by asset class, through the instruments that make up the roughly two hundred positions on the fund's books.

↑ Top

Portfolio and PositionsHoldings and asset classes

---

6.1 Setting the Scene: What the Fund Actually Holds

At the end of Chapter 5 we had a complete description of the Europa Growth Fund: its identity, its three share classes, its fees, its total net assets of 464,552,848.78 EUR on 31 March 2026. What we did not have was any knowledge of how that money is invested. The Portfolios substructure of FundDynamicData, which Chapter 5 left as a placeholder comment, is where the answer lives; and alongside it, outside the <Funds> container at the root level of the document, sits its indispensable companion, AssetMasterData. This chapter treats both.

It is the longest chapter in the book — forty-five pages — and it is long for three reasons. First, the portfolio is structurally the richest part of a FundsXML delivery: it carries every instrument the fund holds, one entry per position, and instruments come in seven or eight broad families (equities, bonds, funds, derivatives, cash, real estate, commodities, alternatives) each with their own specialised fields. Second, the linkage between Portfolio and AssetMasterData through UniqueID is the working expression of design principle 2 from Chapter 3 — linkage by UniqueID, not by nesting — and mastering that linkage is central to every subsequent chapter. Third, portfolio breakdowns, the pre-computed aggregates that feed fact sheets and regulatory reports, have their own structure and their own conventions. All three topics justify the space.

One editorial decision deserves to be stated up front. The Europa Growth Fund, as we have seen, is an actively managed European equity UCITS. It holds roughly 80 to 150 equity positions, a handful of cash accounts in several currencies, and the two currency forwards that implement the CHF hedge for the R-CHF-ACC-HEDGED share class. That is what its real portfolio looks like, and it is what the complete end-to-end example in §6.12 will show. For the asset classes the fund does not hold — bonds, investment funds held as positions, real estate, commodities — the per-asset-class sections use their own isolated examples drawn from generic illustrative funds, and the complete example in §6.12 does not attempt to force these classes into the Europa Growth Fund artificially. The reader who wants to see a bond position renders §6.7's example; the reader who wants to see a derivative in context renders §6.9.4 and the corresponding fragment of §6.12. The integrity of the running example and the coverage of the asset classes can both be preserved without compromise.

By the end of this chapter, you should be able to:

• explain why portfolio positions reference AssetMasterData entries rather than containing them;
• produce a valid UniqueID that links a position to its asset description and defend your choice of generator;
• recognise the common fields that appear on every position, regardless of asset class;
• populate the asset-class-specific fields for equities, bonds, funds, derivatives, cash, and real estate;
• distinguish a derivative's notional from its market value and never again confuse the two;
• compute portfolio breakdowns by sector, country, currency, rating, and maturity from a list of positions, and recognise where breakdowns legitimately differ from a naive recomputation;
• read a complete mixed portfolio of a European equity UCITS on sight and cross-reference every position to its AssetMasterData entry.

The chapter is organised into five parts. Part I (§6.2 and §6.3) establishes the shape of the problem and the linkage mechanism. Part II (§6.4 and §6.5) treats the common fields that appear on every position and every asset. Part III (§6.6 through §6.10) walks through the asset classes one at a time, each with its own specialised fields and a small isolated example. Part IV (§6.11) covers portfolio breakdowns. Part V (§6.12 through §6.14) assembles the complete portfolio of the Europa Growth Fund, lists the common pitfalls, and points at Chapter 7.

---

6.2 Portfolios and AssetMasterData — The Shape of the Problem

Before we look at any field, a step back. The portfolio representation in FundsXML is split into two physically separate blocks — <Portfolios> inside each fund's <FundDynamicData>, and <AssetMasterData> at the root of the document — and the split is the first thing a reader of a FundsXML document notices and the first thing that surprises them. Why not put the full asset description inside each position, as simpler formats do? The answer is the working expression of design principle 2 from Chapter 3, and the motivation is worth making concrete.

Imagine a fund administrator's nightly batch file: twenty funds, each with a hundred and fifty positions, all serialised into a single FundsXML document. Many of those positions reference the same instruments. Siemens is held by twelve of the twenty funds; SAP by eight; Nestlé by fifteen; the short list of European blue chips appears in almost every one of them. If the full asset description of Siemens — its name, its LEI, its GICS classification, its primary listing information, its forty or so static fields — were embedded in every position that referenced it, Siemens would be described twelve times in a single file, each time with the same forty fields, each time vulnerable to a transcription or classification mismatch between copies. A producer that rewrites one copy and forgets another creates a file in which two Siemens entries disagree about what Siemens is, and every downstream consumer that tries to reconcile them has a data-quality problem.

The solution is the one every relational database uses: describe each instrument once, in a central location, and have each position refer to it through an identifier. That central location is <AssetMasterData>, and it sits at the root level of the FundsXML document, outside the <Funds> container, precisely so that it can be shared between several funds in the same delivery. Each position in each fund's portfolio carries only a short pointer — a UniqueID — that tells the consumer where to find the full description. The file is smaller, the descriptions are consistent by construction, and the operational discipline is easier to enforce.

Figure 6.1 — The portfolio/master-data split

                       <FundsXML4>
                            │
          ┌─────────────────┼─────────────────┐
          │                                   │
       <Funds>                         <AssetMasterData>
          │                                   │
    ┌─────┴─────┐                        ┌────┴────┐
    │           │                        │         │
  <Fund>      <Fund>                   <Asset>   <Asset>
    │           │                        ▲         ▲
  Portfolio   Portfolio                  │         │
    │           │                        │         │
 <Position>──┐  │                        │         │
    │        │  │                        │         │
 <Position>──┼──┼──→ UniqueID reference──┘         │
    │        │  │                                  │
    │        └──┼──→ UniqueID reference────────────┘
    │           │
 <Position>─────┼──→ UniqueID reference (shared across funds)
                │
              (etc.)

The figure makes three points. First, both funds in the delivery reach into the same <AssetMasterData> block, and a single asset entry can be referenced by positions in several funds simultaneously. Second, the reference is backward — from position to asset — not forward; there is no "list of holders" on the asset side. Third, the containment hierarchy inside each fund (Portfolio → Position) and the containment hierarchy inside the root (AssetMasterData → Asset) are parallel, and the UniqueID is the only connection between them.

One clarification deserves to be made now, before it becomes a source of confusion later in the chapter: AssetMasterData exists even when the delivery contains a single fund. The Europa Growth Fund is delivered in its own FundsXML file each month-end, not as part of a twenty-fund batch, and yet every one of its deliveries carries a complete <AssetMasterData> block. The reason is not architectural consistency for its own sake; the reason is that the separation keeps positions slim. A Siemens position in the Europa Growth Fund's portfolio contains eight or nine fields (the UniqueID reference, the valuation currency, the single TotalValue in fund currency, the percentage weight, the price date, plus the equity-specific sub-block carrying the unit count, the price and the market value); the Siemens description in AssetMasterData contains forty or more fields covering identifiers, issuer, listing, classifications, ratings, and country-specific extensions. If the two were merged, a portfolio of 150 positions would carry 150 × 40 = 6,000 fields of description when 150 × 9 + 150 × 40 (one description per distinct asset, which, with overlap across funds, is often much smaller) would suffice. Even for a single fund, the separation is operationally meaningful.

Two architectural observations close this section. <Portfolios> lives inside <FundDynamicData> — it belongs to a specific valuation date and is re-emitted whenever a new portfolio snapshot is produced. <AssetMasterData> lives at the root level and applies to the entire delivery. The first is dynamic in the sense that its content changes every valuation day; the second is closer to static, even though in practice it also evolves as new instruments enter the fund's universe. Finally, the two structures must be read together. A portfolio position without its corresponding asset entry is meaningless; an asset entry with no position pointing at it is dead weight. The schema enforces the first half of this discipline directly at parse time — the <UniqueID> on each <Asset> is declared as xs:ID and the <UniqueID> on each <Position> as xs:IDREF, which means a position whose identifier does not match any asset is rejected by any conformant XML parser before any business-level validation even begins. The second half — orphaned asset entries — is not enforced by the schema and shows up only as a data-quality issue. Chapter 10 will formalise both halves as business-validation rules; for this chapter it is enough to carry the pairing in mind at every step.

---

6.3 The UniqueID Linkage in Detail

The UniqueID is the small glue that binds the two sides together. We treat it in three short subsections.

6.3.1 What a UniqueID Is

A UniqueID is a string, typically twenty to forty characters, that uniquely identifies each <Asset> entry inside <AssetMasterData> within a single FundsXML delivery. The schema does not declare it as a plain string — it declares it as xs:ID on the asset side and xs:IDREF on the position side. The practical consequence is twofold. First, the parser checks at load time that every position's UniqueID resolves to exactly one asset entry's UniqueID, and a mismatch is a schema-validation error rather than a business-rule error. Second, the value must conform to the XML Name syntax: it must begin with a letter or underscore, must not contain whitespace, and must be unique across the whole document. ISINs such as DE0007236101 satisfy the syntax because they begin with a letter; purely numeric codes such as a raw five-digit internal reference would not, and producers using numeric internal codes typically prefix them with a letter (EGF-12345) to make them valid XML names.

The scope of uniqueness is important: unlike the UniqueDocumentID of Chapter 4, which must be unique across every delivery a producer has ever emitted, the UniqueID of an asset need only be unique within the file in which it appears. Two deliveries from the same producer may carry different UniqueID values for the same Siemens entry without violating anything, as long as each file is internally consistent. In practice, producers that care about cross-delivery consistency pick a generator that is stable over time (see §6.3.2), but this is a convention, not a schema requirement.

6.3.2 How to Generate a UniqueID

Two strategies dominate production usage, and each has its own strengths.

The first strategy is to use the instrument's ISIN as its UniqueID. The ISIN is already globally unique in the instrument universe, is already present on almost every asset the fund is likely to hold, and is human-readable enough that a debugger looking at a portfolio dump recognises each line at a glance. A position that references DE0007236101 and an asset entry with UniqueID=DE0007236101 are visibly the same instrument; no translation is required. The strategy is so natural that it is the default in most production pipelines.

The weakness of the ISIN strategy is that not every asset has an ISIN. Cash positions do not; over-the-counter derivatives do not; direct real estate holdings do not; some exotic private-equity commitments do not. For these assets, the producer needs a fallback, and that fallback is usually a UUID: a one hundred and twenty-eight-bit random or deterministically-derived identifier, long enough that collisions across producers are astronomically unlikely. The weakness of a UUID is the loss of readability; a debugger sees 7f8e3a2d-... instead of a meaningful name and must perform a mental lookup.

The recommended convention, which Chapter 13 will formalise as a project-level decision, is a hybrid: ISIN when the asset has one, UUID when it does not, and the choice must be deterministic across deliveries. Deterministic means that the same Siemens asset, generated by the same producer on a different day, receives the same UniqueID. For ISIN-bearing assets this is automatic; for UUID-generated assets it requires a UUID v5 (name-based) computed from a stable internal identifier rather than a fresh random v4 on every run. A producer that emits fresh UUIDs every day makes it impossible for consumers to reconcile the same instrument across consecutive deliveries, which is not quite a correctness problem but is a significant operational nuisance.

6.3.3 The Linkage Mechanism in Action

A concrete pair of elements makes the linkage visible. The Europa Growth Fund holds 50,000 shares of Siemens AG. In the portfolio block, inside Fund/FundDynamicData/Portfolios/Portfolio/Positions, the position looks like this:

<Position>
  <UniqueID>DE0007236101</UniqueID>
  <Currency>EUR</Currency>
  <TotalValue>
    <Amount ccy="EUR" isFundCcy="true">8125000.00</Amount>
  </TotalValue>
  <TotalPercentage>1.75</TotalPercentage>
  <PriceDate>2026-03-31</PriceDate>
  <Equity>
    <Units>50000</Units>
    <Price><Amount ccy="EUR">162.50</Amount></Price>
    <MarketValue>
      <Amount ccy="EUR" isFundCcy="true">8125000.00</Amount>
    </MarketValue>
  </Equity>
</Position>

Elsewhere in the same document, inside the root-level <AssetMasterData>, the corresponding asset entry carries the matching UniqueID and the full instrument description:

<Asset>
  <UniqueID>DE0007236101</UniqueID>
  <Identifiers>
    <ISIN>DE0007236101</ISIN>
  </Identifiers>
  <Currency>EUR</Currency>
  <Country>DE</Country>
  <Name>Siemens AG</Name>
  <AssetType>EQ</AssetType>
  <AssetDetails>
    <Equity>
      <StockMarket>XETR</StockMarket>
      <Issuer>
        <Identifiers>
          <LEI>W38RGI023J3WT1HWRP32</LEI>
        </Identifiers>
        <Name>Siemens Aktiengesellschaft</Name>
        <BusinessCountry>DE</BusinessCountry>
        <Type>Non-financial corporations</Type>
      </Issuer>
      <Listing>A</Listing>
    </Equity>
  </AssetDetails>
</Asset>

Four structural points about this pair are worth stating before we look at any single field. First, the position has a mandatory <TotalValue> (typed FundAmountType) that carries the consolidated value of the whole position in the fund's base currency. This is the one number against which the sum of all positions must reconcile to the fund's total net assets; the detail fields inside the asset-class-specific <Equity> child are there for transparency, not to replace the total. Second, the asset-class-specific child — here <Equity> — is one of a choice of twenty-one variants: Equity, Bond, ShareClass, Warrant, Certificate, Option, Future, FXForward, Swap, Repo, FixedTimeDeposit, CallMoney, Account, Fee, RealEstate, REIT, Loan, Right, Commodity, PrivateEquity, and CommercialPaper. Exactly one child of the choice is required at the end of every position. (The asset-master side of the linkage — AssetDetails — has two additional choice members, Index and Crypto, because the schema allows those instruments to be described as assets but not to be held as portfolio positions. §6.5 returns to this asymmetry.) Third, the asset side uses <AssetType> as a two-character discriminator code — EQ for Equity, BO for Bond, SC for fund share class, FX for FX forward, AC for account, and so on — and the asset's detailed fields live inside a separate <AssetDetails> child whose content mirrors the position-side choice by element name. Fourth, the ISIN lives inside <Identifiers>, not as a direct child of <Asset>; the container takes exactly the same shape as the fund-level and share-class-level <Identifiers> blocks of Chapter 5.

A consumer that reads the position finds DE0007236101 in the UniqueID field, jumps to the <AssetMasterData> block, finds the matching <Asset> entry, and now knows everything it needs to know about Siemens as an instrument. It does this lookup once per distinct asset per delivery, caches the results in memory, and processes the whole portfolio without ever re-parsing the asset descriptions. The cost is linear in the number of distinct instruments, not in the number of position-instrument references.

The key rule: consumers never read Portfolio and AssetMasterData in isolation. Both structures together form the complete information about what the fund holds. A production pipeline that parses only one of the two is fundamentally broken, and any validation discipline (Chapter 10) treats the pair as atomic.

Two validation rules flow directly from the linkage. First, every UniqueID in a Position must match exactly one <Asset> in AssetMasterData. As we saw in §6.3.1, the schema enforces this at the parser level through its xs:ID/xs:IDREF pairing; a position whose UniqueID has no target is a schema-validation failure, not a business-rule failure, and the document does not load at all. Second, every <Asset> in AssetMasterData should be referenced by at least one Position. An orphaned asset entry is harmless from a consumer's perspective but is almost always a sign of a sloppy producer — typically the residue of a position that was deleted from the producer's database without a corresponding cleanup of the asset master. Chapter 10 lists this rule among the business-validation checks that a production consumer pipeline should run on every incoming file.

---

6.4 Position-Level Fields

We now descend into the fields. The common position-level fields, which appear on every <Position> element regardless of what asset class the position belongs to, are the subject of this section. Asset-class-specific extras come later in Part III.

Table 6.1 lists the common children of <Position> in the order they must appear.

Table 6.1 — Common children of <Position>

Child element	Schema type	Purpose	Example value
<UniqueID>	xs:IDREF (max 256 chars)	Reference to the matching <Asset> in <AssetMasterData>	DE0007236101
<Identifiers>	IdentifiersType	Optional copy of key instrument codes — redundant with the asset's own Identifiers, present in some pipelines for debugging	—
<Currency>	ISOCurrencyCodeType	Valuation currency of the instrument (its native trading currency, not the fund's base currency)	EUR
<TotalValue>	FundAmountType	The consolidated value of the whole position, in the fund's base currency. Mandatory.	<Amount ccy="EUR">8125000.00</Amount>
<OtherTotalValues>	container	Additional valuations (Hold-To-Maturity, Swing-adjusted, Market, …)	—
<TotalPercentage>	PercentageType	The position's weight in the fund, as a percentage of total net assets	1.75
<AveragePurchasePrice>	FundAmountType	The weighted-average cost basis of the position across all buys	—
<AveragePurchaseFXRate>	FXRatesType	The weighted-average FX rate at which the position was entered	—
<Exposures>	ExposureType	Exposure values under different regulatory approaches (commitment, AIFMD)	—
<FXRates>	FXRatesType	FX rates used in evaluating this position	—
<PriceDate>	xs:date	The date of the price used for this valuation	2026-03-31
<PricingSource>	choice(Listed/Unlisted)	Pricing source — either a listed enumeration (BLOOMBERG, REUTERS, FACTSET, MARKIT, BARCLAYS, JPMORGAN, MERRILL, BROKERS, LPC, NTRS) or free text	BLOOMBERG
asset-class choice	—	Exactly one of <Equity>, <Bond>, <ShareClass>, <Warrant>, <Certificate>, <Option>, <Future>, <FXForward>, <Swap>, <Repo>, <FixedTimeDeposit>, <CallMoney>, <Account>, <Fee>, <RealEstate>, <REIT>, <Loan>, <Right>, <Commodity>, <PrivateEquity> or <CommercialPaper> — mandatory, exactly one	see Part III
<CapitalYieldsTaxClaim>	container	Tax-accrual details at the position level — rarely populated for non-German funds	—
<InflationaryAdjustment>	container	Inflation-linked adjustment fields for index-linked instruments	—
<RiskCodes>	list	Risk indicator values attached to this individual position	—
<Underlyings>	list	Underlying-instrument references for derivatives and structured products	—
<CustomAttributes>	AttributesType	Producer-specific extensions	—

All children except <UniqueID>, <TotalValue>, and the asset-class choice are optional. The three mandatory members carry all the work of position identity, valuation, and asset-class branching, and everything above and below them in the table is supporting detail that producers populate when it matters.

Note on vocabulary: there is no <Quantity> element anywhere on <Position> and no <PositionType> element distinguishing long from short. The schema element named <Position> is of schema type PositionType — the latter being the name of the complex type in the XSD, not a tag name that ever appears in a FundsXML document. The word "quantity" in the prose that follows always refers to the generic concept of "how many of the instrument does the fund hold"; the actual XML tag depends on the asset class and takes its name from the specific choice child (<Units>, <Nominal>, <Shares>, <Contracts>).

Four points about the table deserve to be emphasised in plain text rather than left implicit.

<TotalValue> is mandatory on every position and is the one figure that reconciles against the fund total net assets from Chapter 5. A <Position> element with no <TotalValue> is a schema-validation failure; a <Position> whose <TotalValue> does not match the fund's <TotalNetAssetValue> when summed across all positions is a business-validation failure. The consolidated total lives on the position, not on the asset-class-specific child, because the producer is the authoritative source for how the position rolls up into the fund currency and any downstream consumer should accept that roll-up without recomputing.

The asset-class-specific child is mandatory and the schema offers twenty-one variants. Every <Position> must end with exactly one of <Equity>, <Bond>, <ShareClass>, <Warrant>, <Certificate>, <Option>, <Future>, <FXForward>, <Swap>, <Repo>, <FixedTimeDeposit>, <CallMoney>, <Account>, <Fee>, <RealEstate>, <REIT>, <Loan>, <Right>, <Commodity>, <PrivateEquity> or <CommercialPaper>. This is where the per-class unit count, the per-unit price, and the detail fields live — not at the top of the position. An equity's <Units> field, for example, is a child of <Equity>, not of <Position>. A bond's <Nominal> field is a child of <Bond>. A cash account's balance lives in <Account>/<MarketValue>. The rule is strict and it organises everything that follows in Part III. (Producers describing an index or a crypto asset populate AssetType=IX or AssetType=CR on the asset-master side, but no corresponding choice exists on the position side; a fund holding such instruments emits them as <Equity> or <CommercialPaper> positions, depending on the operational convention.)

The concept of "quantity" does not correspond to a single schema element. Different asset classes describe their unit count with different tag names, each living inside the asset-class choice child:

• For an equity, <Equity>/<Units> carries the number of shares held.
• For a bond, <Bond>/<Nominal> carries the nominal value in the issue currency. A <Nominal>1000000</Nominal> means one million euros face value of bonds, which might be a single bond certificate or a thousand of them depending on the issue's denomination.
• For a fund held as a position, <ShareClass>/<Shares> carries the number of fund units.
• For an option or a future, <Option>/<Contracts> (respectively <Future>/<Contracts>) carries the number of contracts, and the value may be negative to indicate a short position — FundsXML has no separate long/short flag. The same applies to <Swap> legs.
• For cash accounts there is no unit count at all, because an account balance is already a total value carried in <Account>/<MarketValue>.

Section 6.7 will return to the bond case, which is the one that most frequently trips up implementers. The rule to remember is that each asset class has its own idiom and the element name is chosen to reflect it; no element called <Quantity> exists anywhere in the schema, and a producer writing <Quantity> will fail schema validation.

<Amount> elements always carry a ccy attribute. The FundsXML <Amount> element — whether inside <TotalValue>, <Price>, <MarketValue>, <AveragePurchasePrice>, or any other amount-bearing field — names its currency explicitly. In addition, optional boolean attributes isFundCcy, isSubfundCcy, and isShareClassCcy let the producer flag which amount is the fund-base, sub-fund, or share-class currency when several are present. A position holding Swiss Nestlé shares may therefore carry its <TotalValue> with two <Amount> entries — one ccy="EUR" isFundCcy="true" for the fund-base figure, and one ccy="CHF" for the native currency figure — both describing the same economic value at different FX rates. A consumer that ignores the ccy attribute and assumes "everything in the fund's base currency" will misread the Swiss position's native amount and the error will propagate into any downstream calculation.

One final remark before moving to the asset side. Every asset-class-specific field (coupon rate on a bond, strike on an option, counterparty LEI on a cash position) lives inside the asset-class child, not as a direct sibling of <UniqueID> or <TotalValue>. A bond position has <TotalValue> and a <Bond> sub-block containing <Nominal>, <Price>, <DirtyPrice>, <MarketValue>, <InterestClaimGross>, <AccruedInterestDays>, and so on. A cash account position has <TotalValue> and an <Account> sub-block containing <MarketValue> and <Interests>. The asset-class sections in Part III walk through each sub-block in detail; Table 6.1 is the contract for everything outside them.

---

6.5 Asset-Level Fields in AssetMasterData

Symmetrical to §6.4, but from the other side of the linkage: the fields that appear on every <Asset> entry in <AssetMasterData> regardless of asset class. The division of labour between position and asset is straightforward: the position answers the question "how much?", the asset answers the question "what is it?"

Table 6.2 lists the common asset-level fields and their schema types, in the exact order in which they must appear inside <Asset>.

Table 6.2 — Common asset-level fields (schema type AssetType)

Field	Schema type	Mandatory	Purpose
UniqueID	xs:ID	yes	Globally unique identifier within the delivery; target of Position/UniqueID
Identifiers	IdentifiersType	no	ISIN, LEI, GermanWKN, SwissValorenCode, CUSIP, SEDOL, Bloomberg, ReutersRIC, OtherID
DataSupplier	DataSupplierType	no	Producer of this asset record (usually inherited from ControlData)
Currency	ISOCurrencyCodeType	yes	Nominal currency of the instrument (three-letter ISO 4217 code)
IncomeCurrency	ISOCurrencyCodeType	no	Currency in which the instrument's income is paid, if different
Country	ISOCountryCodeType	no	Country of issue (Emissionsland)
Name	Text256Type	yes	Human-readable instrument name
FISN	xs:string (128)	no	ISO 18774 Financial Instrument Short Name
AssetType	enum (2 chars)	yes	Discriminator: EQ/BO/SC/WA/CE/OP/FU/FX/SW/RP/FT/CM/AC/FE/RE/RT/LO/RI/CO/PE/CP/IX/CR
AssetDetails	AssetDetailsType	no	A choice of 23 inline types carrying the asset-class-specific fields
CountrySpecificData	container	no	National reporting extensions (AT, DE, DK, FR, LU, NL)
Securitized	xs:boolean	no	Whether the asset is securitised
IsInfrastructureInvestment	xs:boolean	no	Infrastructure investment flag
InfrastructureInvestmentType	enum	no	Infrastructure category
Ratings	RatingsType	no	Credit ratings from agencies (one entry per agency)
RealEstateCompany	CompanyType	no	Corresponding real-estate company (for direct property holdings)
Classifications	ClassificationsType	no	Sector/industry/style classifications, same structure as in Chapter 5
CustomAttributes	AttributesType	no	Producer-specific extensions

Four points about the table deserve to be emphasised in plain text.

The AssetType element is a two-character code, not an English word. The values are EQ for equity, BO for bond, SC for fund share class, WA for warrant, CE for certificate, OP for option, FU for future, FX for FX forward, SW for swap, RP for repo, FT for fixed-time deposit, CM for call money, AC for account, FE for fee, RE for real estate, RT for REIT, LO for loan, RI for right, CO for commodity, PE for private equity, CP for commercial paper, IX for index, CR for crypto. These are the operational codes used by fund accounting systems across Europe, and producers coming from such systems usually have the mapping built in already. A consumer that reads AssetType branches its parser on the two-letter code, loads the corresponding AssetDetails child, and applies the asset-class-specific logic. There is no enumeration with English labels anywhere in the schema.

The ISIN is not a direct child of <Asset>. The ISIN lives inside <Identifiers>, the same container we met at the fund and share-class level in Chapter 5. So does the LEI (used for issuers, not for the asset itself), the GermanWKN, the SwissValorenCode, and every other instrument code. A typical equity asset entry begins with <UniqueID>, then <Identifiers><ISIN>...</ISIN><GermanWKN>...</GermanWKN></Identifiers>, then <Currency>, then <Country>, then <Name>, then <AssetType>, then <AssetDetails>. Producers that write the ISIN as a top-level child will fail schema validation.

AssetDetails is the home of asset-class-specific fields, not a collection of siblings of <Asset>. Everything that distinguishes an equity from a bond — the issuer block, the stock market, the coupon, the maturity, the strike, the counterparty of a forward, the counterparty of a cash account — lives one level below, inside an <AssetDetails> child whose content is exactly one of twenty-three sub-elements (Equity, Bond, ShareClass, Warrant, Certificate, Option, Future, FXForward, Swap, Repo, FixedTimeDeposit, CallMoney, Account, Fee, RealEstate, REIT, Loan, Right, Commodity, PrivateEquity, CommercialPaper, Index, Crypto). The element names match the ones on the position-side choice of §6.4 deliberately, so that the discriminator on both sides is the same word, not a mapping a consumer has to learn.

Issuer and instrument are distinct, and the schema respects that distinction. An asset entry has two identity layers. The instrument is the tradable unit — a specific equity share class, a specific bond issue, a specific derivative contract — and it is identified at the top of <Asset> by its own <Identifiers> block, whose <ISIN> (or <UniqueID>, for instruments without an ISIN) is the primary key. The issuer is the legal entity that issued the instrument — and it is identified by a separate <Issuer> block of schema type CompanyType that lives inside AssetDetails/<Equity> or AssetDetails/<Bond>. CompanyType carries its own <Identifiers> container with the issuer's LEI, a mandatory <Name>, optional <LegalName>, <LegalForm>, <Address>, <BusinessCountry>, <ParentCompany> for corporate hierarchies, an <OtherClassification> container, and a <Type> enumeration covering the ECB sector categories (Non-financial corporations, Central bank, Deposit-taking corporations except the central bank, General government, Insurance corporations, Pension funds, Money market funds, Non-MMF investment funds, and five others). For equities the instrument-issuer relationship is typically one-to-one: the Siemens AG legal entity has one LEI, and DE0007236101 is the ordinary common stock of that entity. For bonds the relationship is one-issuer-to-many-instruments: the Federal Republic of Germany has one LEI but hundreds of bund series, each with its own ISIN, all backed by the same <Issuer> block carrying the Federal Republic's LEI and Type="General government". Section 6.7 returns to this point in the context of bond-specific fields.

All asset-class-specific fields — the strike of an option, the maturity of a bond, the counterparty of a forward — live inside <AssetDetails> below the common fields of Table 6.2. The five sections that follow treat them one asset class at a time.

---

6.6 Equities

The primary case for the Europa Growth Fund. Three subsections.

6.6.1 The Equity Asset Model

An equity asset entry in AssetMasterData describes a tradable share class of a public company. Its structure has two layers: the generic asset-level fields of Table 6.2, populated with AssetType=EQ, followed by an AssetDetails/Equity child whose content follows the schema type EquityType. The generic fields carry identity and classification; the equity-specific fields carry listing, issuer, and equity-specific metadata.

Identifiers live inside the top-level <Identifiers> block of Table 6.2, not inside <Equity>. The primary identifier is the ISIN, twelve characters, ISO 6166. For securities that also trade in non-ISIN-using markets, FundsXML carries additional identifier fields in the same container: SEDOL for UK listings, CUSIP for North-American instruments, and GermanWKN for German securities. Bloomberg tickers and Reuters RICs have their own dedicated fields (Bloomberg with Ticker, Exchange, Market, BBGID sub-children; ReutersRIC with a type attribute).

Inside <Equity>, the schema type EquityType (XSD §25059) carries the following children in order:

• ClassOfBusiness — a structured IndustryProviderType block with Offeror, Date, Value, and optional Text, naming the sector classification provider (e.g. Bloomberg, GICS) and the value.
• StockMarket — one or more MICCodeType values (ISO 10383 four-character market identifier codes) naming the exchanges on which the equity is listed. XETR for Xetra, XPAR for Euronext Paris, XVTX for SIX Swiss Exchange, XAMS for Euronext Amsterdam, XLON for the London Stock Exchange, XMAD for Bolsa de Madrid. The element repeats for multi-listed stocks.
• Issuer — a structured CompanyType block identifying the issuing legal entity: <Identifiers> with the issuer's LEI, a mandatory <Name>, an optional <LegalForm>, an optional <BusinessCountry>, and an optional <Type> from the ECB sector enumeration.
• Listing — an enumeration A/B/G/K/M/S/V/Y/Z indicating the kind of exchange listing. A (official market) is the ordinary case for blue-chip European stocks; K means not listed, used for private or unlisted issues.
• ParValue — the nominal value of the share in the instrument's currency (often 1.00 for modern no-par-value shares).
• WithholdingTaxRate — the producer's default withholding tax rate on dividends from this instrument.
• MarketCapitalization — a Date/Value pair carrying the full market capitalisation of the issuer as at that date.
• CustomMarketCapitalization — a Name/Date/Value triple where Name is drawn from the enumeration Small Cap, Small & Mid Cap, Mid Cap, Mid & Large Cap, Large Cap, All Cap, Other. This is the field a factsheet engine reads when it needs a size bucket.
• Industries — a container for one or more IndustryCode entries, each with Name (the classification scheme, e.g. GICS), Date, and Value (the numeric or textual code within that scheme).

Classification through AssetType/Classifications. The generic-asset <Classifications> block from Table 6.2 is the more idiomatic place to carry sector-classification values for downstream consumers. Following the same pattern as in Chapter 5, each <Classification> entry names a provider via <ListedGroup> (EFAMA, MORNINGSTAR, LIPPER, BLOOMBERG, MIFID, BVI, VOEIG, ESMA, AMF, WM, CIC, CFI) or <UnlistedGroup> (free text, used for GICS and ICB which are not in the enumeration) and supplies one or more <Value> elements with optional level attributes for hierarchies. The <Industries> and <ClassOfBusiness> fields inside <Equity> are historical and mostly populated by legacy fund-accounting systems; modern producers prefer <Classifications>.

Table 6.3 — Equity-specific fields inside AssetDetails/Equity (schema type EquityType)

Field	Schema type	Example	Mandatory
ClassOfBusiness	IndustryProviderType	Offeror=Bloomberg, Value=BICS	optional
StockMarket	MICCodeType (repeats)	XETR	optional
Issuer	CompanyType	see text above	optional
Listing	enum A/B/G/K/M/S/V/Y/Z	A	optional
ParValue	xs:decimal	1.00	optional
WithholdingTaxRate	xs:decimal	26.375	optional
MarketCapitalization	Date + Value	2026-03-31, 145 bn	optional
CustomMarketCapitalization	Name enum + Date + Value	Large Cap	optional
Industries	list of IndustryCode	GICS 20106010	optional

All equity-level fields are optional; an <Equity> element with no children at all is schema-valid (an empty but schema-valid element). In practice, producers populate Issuer, StockMarket, and at least one classification entry for every equity in the portfolio; the rest depend on the producer's downstream consumers.

6.6.2 Position-Level Fields Specific to Equities

At the position level, an equity entry ends with an <Equity> child (defined inline as an anonymous complex type within <Position>, XSD §28571) whose mandatory first child is <Units>. Its sequence is:

• <Units> (mandatory, xs:decimal) — the number of shares the fund holds. Almost always a whole number for traditional long-only UCITS; fractional shares exist in a few specialised vehicles (robo-advisors offering fractional investment, some unit-linked wrappers) but do not appear in the Europa Growth Fund or in most European institutional portfolios.
• <Price> (optional, FundAmountType) — the last available quote, in the listing currency, typically the closing price on the valuation date at the primary listing. If the stock was suspended for the day, the price holds at the last valid quote and the position's <PriceDate> (inside the parent <Position>) reflects the age of the quote.
• <OtherPrices> (optional) — additional prices (hold-to-maturity-style alternatives, rarely used for equities).
• <MarketValue> (optional, FundAmountType) — Units × Price, converted into the fund's base currency if the listing currency differs. The conversion rate is the producer's reference rate at the valuation point.
• <BookRate> (optional, FundAmountType) — the book value used for capital-gains accounting.
• <PurchaseValue> (optional, FundAmountType) — the historical cost of the position.
• <DividendsDue> (optional, FundAmountType) — the dividend income that has accrued between the last ex-dividend date and the valuation date but has not yet been paid out. Most producers do not populate it; they treat dividends as discrete events that flow through Distributions on the share class (Chapter 7) rather than accruing into the equity position.
• <LendedFlag> (optional, xs:boolean) — whether part of the position is out on loan to a counterparty.
• <LendedUnits> (optional, xs:decimal) — the number of shares out on loan.
• <IndicatorRaffled> (optional, xs:boolean) — whether the security has been drawn by lot in a corporate action.

Note what is not a child of <Equity> but lives one level up on <Position>: TotalValue, TotalPercentage, Currency, PriceDate, PricingSource. Those are position-level concerns and are common to every asset class. A producer that writes <TotalValue> as a sibling of <Units> inside <Equity> is wrong; the field must appear at <Position> level.

6.6.3 Equity Example: A Siemens Position

A complete pair — position and asset entry — for the Europa Growth Fund's Siemens holding on 31 March 2026.

<!-- Inside Fund/FundDynamicData/Portfolios/Portfolio/Positions -->
<Position>
  <UniqueID>DE0007236101</UniqueID>
  <Currency>EUR</Currency>
  <TotalValue>
    <Amount ccy="EUR" isFundCcy="true">8125000.00</Amount>
  </TotalValue>
  <TotalPercentage>1.75</TotalPercentage>
  <PriceDate>2026-03-31</PriceDate>
  <Equity>
    <Units>50000</Units>
    <Price>
      <Amount ccy="EUR">162.50</Amount>
    </Price>
    <MarketValue>
      <Amount ccy="EUR" isFundCcy="true">8125000.00</Amount>
    </MarketValue>
  </Equity>
</Position>

<!-- Elsewhere, inside the root AssetMasterData block -->
<Asset>
  <UniqueID>DE0007236101</UniqueID>
  <Identifiers>
    <ISIN>DE0007236101</ISIN>
    <GermanWKN>723610</GermanWKN>
  </Identifiers>
  <Currency>EUR</Currency>
  <Country>DE</Country>
  <Name>Siemens AG</Name>
  <AssetType>EQ</AssetType>
  <AssetDetails>
    <Equity>
      <StockMarket>XETR</StockMarket>
      <Issuer>
        <Identifiers>
          <LEI>W38RGI023J3WT1HWRP32</LEI>
        </Identifiers>
        <Name>Siemens Aktiengesellschaft</Name>
        <BusinessCountry>DE</BusinessCountry>
        <Type>Non-financial corporations</Type>
      </Issuer>
      <Listing>A</Listing>
      <CustomMarketCapitalization>
        <Name>Large Cap</Name>
        <Date>2026-03-31</Date>
        <Value>145000000000</Value>
      </CustomMarketCapitalization>
      <Industries>
        <IndustryCode>
          <Name>GICS</Name>
          <Date>2026-03-31</Date>
          <Value>20106010</Value>
        </IndustryCode>
      </Industries>
    </Equity>
  </AssetDetails>
  <Classifications>
    <Classification>
      <UnlistedGroup>GICS</UnlistedGroup>
      <Type>Sector</Type>
      <Language>en</Language>
      <Value level="1">Industrials</Value>
      <Value level="2">Industrial Conglomerates</Value>
    </Classification>
  </Classifications>
</Asset>

Reading field by field: the position's <UniqueID> is the ISIN, following the convention of §6.3.2 (and satisfying the xs:ID constraint because DE0007236101 begins with a letter). The consolidated <TotalValue> is 8.125 million euros — approximately 1.75% of the fund's total net assets from Chapter 5 — and lives in the fund's base currency, flagged isFundCcy="true". Inside <Equity>, the position says the fund holds 50,000 Siemens shares, last priced at 162.50 EUR at Xetra's close on 31 March 2026, with a market value equal to Units × Price also in euros.

The asset entry confirms the instrument identity. <Identifiers> carries the ISIN and the six-character German WKN (723610, the historical code that German retail systems still use alongside the ISIN). The top-level <Currency> names the instrument's nominal currency (EUR) and <Country> names the country of issue (DE). <AssetType>EQ</AssetType> signals the asset-class to consumers. Inside <AssetDetails>/<Equity>, the listing information — Xetra (XETR) as the stock market, A (official market) as the listing category — sits above the issuer block. The issuer block is a full <Issuer> element of schema type CompanyType, with Siemens AG's LEI (20 characters, ISO 17442), a mandatory name, a business country, and an ECB-sector classification of Non-financial corporations. A <CustomMarketCapitalization> entry places Siemens in the Large Cap bucket as at 31 March 2026 with a rounded-EUR figure, and an <Industries> entry carries the GICS industry code 20106010 (Industrial Conglomerates) for downstream consumers that speak that taxonomy.

The top-level <Classifications> block — sibling of <AssetDetails> — duplicates the GICS classification in the idiomatic form that the rest of the book uses: an <UnlistedGroup>GICS</UnlistedGroup> (because GICS is not a listed provider in the schema's enumeration), a <Type>Sector</Type>, a <Language>en</Language>, and two <Value> elements with level attributes walking the hierarchy from Industrials down to Industrial Conglomerates. A consumer that reads this block picks whichever scheme it recognises.

A consumer that produces a factsheet for the fund renders Siemens as "Siemens AG, 1.75%, Industrials, Germany" using five or six of the visible fields. A consumer that produces a regulatory report reads the LEI and the GICS code for their respective disclosures. The same pair serves every downstream use case without any additional data.

This pair is the template that §6.12 will repeat fifteen times with different companies, sectors, and countries. The fields are always the same; the values vary.

---

6.7 Bonds

The Europa Growth Fund holds no bonds, but any treatment of FundsXML portfolios must cover them because bonds are structurally the most different asset class from equities and because most European fund portfolios outside pure equity mandates contain at least some. The example in this section comes from a generic European bond fund rather than from the Europa Growth Fund.

Bonds are more complex than equities for one overriding reason: a bond carries two identities rather than one. The instrument is a specific bond issue with a specific maturity and coupon; the issuer is the legal entity that issued it. Where an equity share class is in one-to-one correspondence with its issuer's LEI, a single issuer may have issued dozens or hundreds of distinct bonds, each with its own ISIN and its own behaviour, all backed by the same credit. The bond asset model must represent both layers.

6.7.1 The Bond Asset Model

An <Asset> entry for a bond carries AssetType=BO, and its bond-specific details live inside <AssetDetails>/<Bond> (schema type BondType, XSD §2012). The type is large — thirty or more optional children — and the sequence below lists only the fields that matter for a typical European fund portfolio.

Convertible flag. The one mandatory child of BondType is <ConvertibleFlag> (xs:boolean). Every bond must state whether it carries equity conversion rights, even if the answer is trivially false for a straight government bond. Convertible bonds have an additional <ConvertibleBond> sub-block with strike and conversion ratio details.

Issuer. A structured CompanyType block identifying the issuing legal entity — the same type we saw for equities in §6.6.1, but the issuer for a bond is almost always populated more richly because rating agencies, regulatory reporting, and concentration limits all hang on it. Issuer/Identifiers/LEI is the single most important field on the whole entry.

Listing. <StockMarket> (repeatable MIC codes) and <Listing> (the same A/B/G/K/M/S/V/Y/Z enumeration as for equities) identify the exchanges on which the bond trades. A <ListingUnit> field, unique to bonds, distinguishes P (pieces — bonds denominated in whole certificates) from N (nominal amount — the more common case in Europe). For a typical German bund, ListingUnit=N.

Maturity and key dates.

• IssueDate — the date the bond was originally issued.
• MaturityDate — the date on which the principal is repaid to investors.
• DateFirstCoupon and DateLastCoupon — the boundary coupon dates.
• CouponDate — the next scheduled coupon payment.

Coupon. The cash flow the bond pays to investors during its life is carried inside a <Coupon> sub-block with four children:

• <Type> — an enumeration fix/float/zero/others. Note the lowercase spelling; the schema uses fix, not Fixed.
• <PaymentFrequency> (FrequencyType) — a SWIFT-style four-letter code: DAIL (daily), WEEK (weekly), TWWK (two-weekly), MNTH (monthly), TWMN (two-monthly), QURT (quarterly), SEMI (semi-annual), YEAR (annual). Most European government bonds pay YEAR, most corporate bonds SEMI. These are the same codes the EMT/EPT regulatory templates of Chapter 8 use, so producers coming from that side of the house have the mapping already.
• <InterestRate> (xs:decimal) — the nominal coupon rate as a percentage of nominal value (2.50 for a 2.50% coupon).
• For floating-rate notes, <BaseIndex> (IdentifiersType) and <OffsetBPS> (xs:decimal) describe the floating rate formula.

Redemption. A <RedemptionRate> (xs:decimal) carries the price at which the bond will be redeemed at maturity — typically 100.00 (par). An optional <Redemption> sub-block carries the redemption type (Bullet or Sinkable), any call/put option date, the direction of the option (Issuer, Bearer, or Both), and the option strike price where relevant.

Tax fields. <WithholdingTaxRate>, <EUWithholdingTaxRate>, <EUWithholdingTaxCategory> (A/B/C) and <CapitalYieldsTaxKind> cover the various European withholding regimes. Most producers populate only the first.

The single biggest surprise in the bond type. There is no BondType enumeration. The schema does not distinguish a Government bond from a Corporate bond from a Covered bond at the <Bond> level; that distinction is carried through Issuer/Type (the ECB-sector enumeration: General government, Non-financial corporations, Deposit-taking corporations, and so on) and through the <Classifications> block on <Asset>. Similarly, there is no CountryOfRisk element, no DayCountConvention enumeration, and no Seniority field. The producer who needs these concepts must carry them in <Classifications> or <CustomAttributes>.

Credit ratings live on <Asset> itself (not inside <Bond>) under <Ratings>, schema type RatingsType. The structure is slightly unusual: the outer container has one <Rating> child per agency, and each agency <Rating> wraps a RatingCompany name and one or more inner <Rating> entries carrying the actual rating values. An agency's rating history is a sequence of inner entries; the current rating is the most recent one. A bond rated by three agencies therefore has three outer <Rating> entries, one per agency, each with at least one inner <Rating> entry.

Table 6.4 — Key bond-specific fields inside AssetDetails/Bond (schema type BondType)

Field	Schema type	Example	Mandatory
ConvertibleFlag	xs:boolean	false	yes
Issuer	CompanyType	Federal Republic of Germany	optional but expected
StockMarket	MICCodeType (repeats)	XETR	optional
Listing	enum A/B/G/K/M/S/V/Y/Z	A	optional
ListingUnit	enum P/N	N	optional
IssueDate	xs:date	2024-02-15	optional
MaturityDate	xs:date	2034-02-15	optional
CouponDate	xs:date	2027-02-15	optional
Coupon/Type	enum fix/float/zero/others	fix	optional
Coupon/PaymentFrequency	FrequencyType	YEAR	optional
Coupon/InterestRate	xs:decimal	2.50	optional
RedemptionRate	xs:decimal	100.00	optional
Redemption/Type	enum Bullet/Sinkable	Bullet	optional
InterestRate	xs:decimal	2.50	optional
InterestsStartDate	xs:date	2026-02-15	optional

6.7.2 Position-Level Fields Specific to Bonds

At the position level, a bond entry ends with a <Bond> child (defined inline as an anonymous complex type within <Position>, XSD §28640) whose mandatory first child is <Nominal>. Its sequence is:

• <Nominal> (mandatory, xs:decimal) — the nominal value of the bonds held, in the issue currency. <Nominal>1000000</Nominal> means one million of nominal value, not one million pieces. This is the single most confusing convention in bond accounting for first-time implementers, and it is worth stating three times: bond <Nominal> is nominal, bond <Nominal> is nominal, bond <Nominal> is nominal. The total value of a bond position at par is therefore Nominal × (Price / 100), because Price is expressed as a percentage of nominal.
• <OriginalFace> (optional) — the par value at the time of purchase, used for sinking-fund bonds whose nominal has been reduced through partial redemptions.
• <Price> (optional, FundAmountType) — the clean price, expressed as a percentage of nominal value. A bond trading at par has price 100.00, a bond at a five-point discount has price 95.00.
• <OtherPrices> (optional) — additional price quotes (hold-to-maturity, for example).
• <DirtyPrice> (optional, FundAmountType) — the clean price plus accrued interest, expressed as a percentage of nominal.
• <MarketValue> (optional, FundAmountType) — the market value of the position without interest, computed as Nominal × (Price / 100).
• <InterestClaimNet> and <InterestClaimGross> (optional, FundAmountType) — the net and gross accrued interest in the bond's currency. The net/gross distinction reflects withholding tax treatment.
• <AccruedInterestDays> (optional, xs:integer) — the number of days of interest that have accrued, as an audit field for consumers that want to verify the producer's computation.
• <ZeroBondInterestClaimNet>, <ZeroBondInterestClaimGross>, <ZeroBondCapitalYieldsTaxClaim>, <ZeroBondYield> — analogues for zero-coupon bonds.
• <Indexfactor>, <Poolfactor> — for index-linked and pass-through bonds.
• <BookRate>, <PurchaseValue> — cost basis fields.
• <LendedFlag>, <LendedUnits>, <IndicatorRaffled>, <CollateralValue> — loan and corporate-action fields shared with equities.

Clean price, dirty price, and position total. Bonds trade on clean price in European markets — a price that excludes accrued interest. The clean price is what gets quoted on trading screens and in newspaper tables. When an investor actually buys a bond, they pay the clean price plus the accrued interest since the last coupon date — the dirty price — because the seller is entitled to the portion of the next coupon that has accumulated during their ownership. FundsXML follows the clean-price convention for <Bond>/<Price> and models the accrued interest through <Bond>/<InterestClaimGross> (or InterestClaimNet) as a separate field, and optionally through <Bond>/<DirtyPrice> as the combined figure.

The position's consolidated <TotalValue> at the <Position> level is therefore:

TotalValue = Nominal × (Price / 100) + InterestClaimGross

A consumer that computes the total as Nominal × Price without the percentage scaling will get an answer that is wrong by a factor of one hundred. A consumer that reads only <Bond>/<MarketValue> and omits the accrued interest will understate the position by the coupon accrual — small in absolute terms but meaningful for yield and duration calculations. In practice, the producer emits all three fields (MarketValue, InterestClaimGross, and the parent <Position>/<TotalValue> as the sum), and the consumer reads whichever it needs.

Optional analytics such as yield-to-maturity, modified duration, and convexity are not first-class fields of <Bond>. A producer that wants to ship them does so either through <OtherPrices> with a descriptive type label or through <CustomAttributes> on the asset entry. Most producers do not populate them; consumers who need them compute them locally from the bond's characteristics.

6.7.3 Bond Example: A German Bund Position

A generic European bond fund holds a position in a ten-year German federal government bond: nominal value 1,000,000 EUR, coupon 2.50%, maturity 15 February 2034, clean price 98.75 at the 31 March 2026 valuation. The accrued interest since the last coupon payment on 15 February 2026 is approximately 3,150 EUR (44 days at 2.50% on 1,000,000 EUR nominal).

<!-- Portfolio position -->
<Position>
  <UniqueID>DE0001102614</UniqueID>
  <Currency>EUR</Currency>
  <TotalValue>
    <Amount ccy="EUR" isFundCcy="true">990650.68</Amount>
  </TotalValue>
  <TotalPercentage>0.99</TotalPercentage>
  <PriceDate>2026-03-31</PriceDate>
  <Bond>
    <Nominal>1000000</Nominal>
    <Price>
      <Amount ccy="EUR">98.75</Amount>
    </Price>
    <DirtyPrice>
      <Amount ccy="EUR">99.06507</Amount>
    </DirtyPrice>
    <MarketValue>
      <Amount ccy="EUR" isFundCcy="true">987500.00</Amount>
    </MarketValue>
    <InterestClaimGross>
      <Amount ccy="EUR">3150.68</Amount>
    </InterestClaimGross>
    <AccruedInterestDays>44</AccruedInterestDays>
  </Bond>
</Position>

<!-- Corresponding asset entry -->
<Asset>
  <UniqueID>DE0001102614</UniqueID>
  <Identifiers>
    <ISIN>DE0001102614</ISIN>
  </Identifiers>
  <Currency>EUR</Currency>
  <Country>DE</Country>
  <Name>Bundesrepublik Deutschland 2.50% 02/2034</Name>
  <AssetType>BO</AssetType>
  <AssetDetails>
    <Bond>
      <ConvertibleFlag>false</ConvertibleFlag>
      <Issuer>
        <Identifiers>
          <LEI>529900PY3MOXO1E5MD14</LEI>
        </Identifiers>
        <Name>Federal Republic of Germany — Finance Agency</Name>
        <BusinessCountry>DE</BusinessCountry>
        <Type>General government</Type>
      </Issuer>
      <ListingUnit>N</ListingUnit>
      <IssueDate>2024-02-15</IssueDate>
      <MaturityDate>2034-02-15</MaturityDate>
      <CouponDate>2027-02-15</CouponDate>
      <Coupon>
        <Type>fix</Type>
        <PaymentFrequency>YEAR</PaymentFrequency>
        <InterestRate>2.50</InterestRate>
      </Coupon>
      <RedemptionRate>100.00</RedemptionRate>
      <Redemption>
        <Type>Bullet</Type>
      </Redemption>
      <InterestRate>2.50</InterestRate>
      <InterestsStartDate>2026-02-15</InterestsStartDate>
    </Bond>
  </AssetDetails>
  <Ratings>
    <Rating>
      <RatingCompany>MOODYS</RatingCompany>
      <Rating>
        <Date>2025-06-15</Date>
        <Value>Aaa</Value>
        <Description>Long-term issuer credit rating — stable outlook</Description>
      </Rating>
    </Rating>
    <Rating>
      <RatingCompany>STANDARD-POORS</RatingCompany>
      <Rating>
        <Date>2025-05-20</Date>
        <Value>AAA</Value>
        <Description>Long-term foreign currency — stable outlook</Description>
      </Rating>
    </Rating>
    <Rating>
      <RatingCompany>FITCH</RatingCompany>
      <Rating>
        <Date>2025-07-02</Date>
        <Value>AAA</Value>
        <Description>Long-term issuer default rating — stable outlook</Description>
      </Rating>
    </Rating>
  </Ratings>
  <Classifications>
    <Classification>
      <ListedGroup>ESMA</ListedGroup>
      <Type>Bond Type</Type>
      <Language>en</Language>
      <Value>Sovereign</Value>
    </Classification>
  </Classifications>
</Asset>

Reading this pair: the position holds one million euros nominal of the 2.50% bund maturing 15 February 2034. The clean price is 98.75 (a small discount to par, reflecting a yield slightly above the coupon). The accrued interest of 3,150.68 EUR is the coupon income earned in the forty-four days since the 15 February 2026 payment, expressed as <InterestClaimGross> inside <Bond>. The position-level <TotalValue> is 990,650.68 EUR — the sum of <Bond>/<MarketValue> (987,500.00 EUR = 1,000,000 × 0.9875) and the interest claim. The <DirtyPrice> of 99.06507 is the clean price plus accrued expressed as a percentage, and consumers that prefer to read a single price number use it.

The asset entry carries the mandatory <ConvertibleFlag>false</ConvertibleFlag> as the first child of <Bond> — even for a vanilla government bond. The <Issuer> block names the Federal Republic's bond-issuing agency with its LEI, a business country of DE, and an ECB sector classification of General government; this is where the "sovereign" nature of the bond is encoded, not in any BondType enumeration. The <ListingUnit>N</ListingUnit> declares that the bond trades by nominal, matching the position-level <Nominal> idiom. The <Coupon> sub-block uses the <PaymentFrequency>YEAR</PaymentFrequency> code for an annual coupon, and <Type>fix</Type> (lowercase, as the schema demands) for the fixed-rate nature. The <Redemption><Type>Bullet</Type></Redemption> declares that the bond is redeemed in a single payment at maturity, not in a sinking-fund pattern.

The <Ratings> block carries three agency entries — Moody's, Standard & Poor's, and Fitch — each wrapping a <RatingCompany> name and one inner <Rating> entry with date, value, and description. All three agree on AAA (or Aaa in Moody's scale), as one would expect for German government paper. A consumer that needs the middle of the three ratings can read all three and apply its own logic; a consumer that wants the most conservative picks the lowest. A <Classifications> entry under <ListedGroup>ESMA</ListedGroup> classifies the bond as Sovereign for downstream consumers that want a textual label without walking into the issuer type.

The bond example shows every structural feature that distinguishes bonds from equities: the nominal-quantity convention, the clean/dirty price split, the rich issuer information, the multiple rating agencies, and the surprising absence of a BondType enumeration in favour of issuer-sector and classifications-based categorisation. A European bond fund's portfolio is a long list of entries of this shape, one per issue.

---

6.8 Investment Funds

The case in which a fund holds another fund's shares as a position. For a pure equity UCITS like the Europa Growth Fund this is a minor pattern — the fund occasionally holds a European equity ETF as a liquidity substitute — but for a fund-of-funds it is the dominant pattern, and either way the asset class deserves its own treatment.

6.8.1 The Fund-as-an-Asset Model

A held fund is represented in AssetMasterData as an <Asset> element whose <AssetType> is SC (Share Class), not a nested <Fund> element. The discriminator is a deliberate reminder that from the holder's perspective, what is owned is always a specific share class of a fund — the euro-distributing class, the CHF-hedged class, the institutional class — never the fund as an abstraction. In Chapter 5 we spent twenty pages establishing that investable units are share classes; here we see the same principle applied from the other side.

A fund-of-funds that holds six underlying funds therefore carries six <Asset> entries with AssetType=SC, not six nested <Fund> elements. Each position in the portfolio has a <ShareClass> child carrying its unit count and valuation, and each asset entry describes the held share class as an instrument. The portfolio-asset linkage mechanism is uniform across all asset classes, and introducing a nested-fund exception would complicate every consumer's parsing logic for no benefit.

Share-class details inside AssetDetails/<ShareClass> (schema type ShareClassDetailsType, XSD §32804) are surprisingly minimal. The schema treats a held share class as just another tradable instrument, and most of the rich fund-level metadata from Chapter 5 (legal structure, domicile, benchmarks, classifications, SFDR product type) is not duplicated on the holder's side. ShareClassDetailsType carries only:

• Issuer — a CompanyType block identifying the fund's management company or promoter.
• StockMarket — one or more MIC codes for the exchanges on which the share class trades (relevant only for listed share classes such as ETFs).
• Listing — the same A/B/G/K/M/S/V/Y/Z enumeration as for equities.
• ListingUnit — U (units) or N (nominal), almost always U.
• IssueDate — the share class's inception date.
• MaturityDate — the share class's maturity date, for closed-ended vehicles.
• WithholdingTaxRate — the tax rate applied to distributions.
• ShareClassType — a ShareClassTypeType block with Code, EarningUse (D/P/R), and short/long names, mirroring the structure we met at ShareClass/ShareClassType in Chapter 5.
• ExchangeTradedFundFlag (xs:boolean) — a dedicated flag for ETFs, distinct from the generic listing enumeration.

Fields that the schema does not carry on a held share class are, notably, FundLegalType, FundCategory, OngoingCharges, and any explicit lookthrough flag. The legal type of a held fund, where relevant, lives in <Classifications> on the outer <Asset> (for example <ListedGroup>ESMA</ListedGroup> with <Value>UCITS</Value>). The held fund's ongoing charges figure — relevant for the holding fund's own MiFID II cost disclosure — is not a field on the instrument at all; it is delivered through the regulatory templates of Chapter 8, specifically the EMT section that aggregates per-instrument charges, and through <CustomAttributes> on the asset entry for producers that want to carry it inline.

The lookthrough concept deserves a short explanation. For certain regulatory calculations — concentration limits, ESG exposure aggregation, Solvency II capital charges — the regulator asks not "what funds does this fund hold?" but "what underlying assets does this fund ultimately hold?" Lookthrough requires the holder to obtain the underlying composition of each held fund and aggregate it into its own exposure calculation. FundsXML carries the decomposition data itself through Portfolio/PositionsDecomposed, a dedicated sibling of <Positions> that replaces held share classes with the scaled-down positions of the underlying fund. A producer that wants to offer lookthrough data to its consumers populates <PositionsDecomposed> with the underlying positions and a <LookThroughLevels> count stating how deep the decomposition went; a consumer that needs lookthrough reads from <PositionsDecomposed> rather than from <Positions>. There is no boolean "lookthrough required" flag anywhere on the share-class instrument.

6.8.2 Fund Position Example

A small illustrative example — not from the Europa Growth Fund, because a pure equity UCITS rarely holds ETFs of its own asset class, but from a generic European multi-asset fund that parks liquidity in the iShares Core MSCI Europe UCITS ETF EUR (Acc) (ISIN IE00B4K48X80) while awaiting deployment.

<!-- Portfolio position -->
<Position>
  <UniqueID>IE00B4K48X80</UniqueID>
  <Currency>EUR</Currency>
  <TotalValue>
    <Amount ccy="EUR" isFundCcy="true">2000250.00</Amount>
  </TotalValue>
  <TotalPercentage>0.43</TotalPercentage>
  <PriceDate>2026-03-31</PriceDate>
  <ShareClass>
    <Shares>22500</Shares>
    <Price>
      <Amount ccy="EUR">88.90</Amount>
    </Price>
    <PurchaseValue>
      <Amount ccy="EUR">1987420.00</Amount>
    </PurchaseValue>
  </ShareClass>
</Position>

<!-- Asset entry -->
<Asset>
  <UniqueID>IE00B4K48X80</UniqueID>
  <Identifiers>
    <ISIN>IE00B4K48X80</ISIN>
  </Identifiers>
  <Currency>EUR</Currency>
  <Country>IE</Country>
  <Name>iShares Core MSCI Europe UCITS ETF EUR (Acc)</Name>
  <AssetType>SC</AssetType>
  <AssetDetails>
    <ShareClass>
      <Issuer>
        <Identifiers>
          <LEI>549300MS535KC2WH4Z30</LEI>
        </Identifiers>
        <Name>BlackRock Asset Management Ireland Limited</Name>
        <BusinessCountry>IE</BusinessCountry>
        <Type>Non-MMF investment funds</Type>
      </Issuer>
      <StockMarket>XETR</StockMarket>
      <Listing>A</Listing>
      <ListingUnit>U</ListingUnit>
      <IssueDate>2009-09-29</IssueDate>
      <ExchangeTradedFundFlag>true</ExchangeTradedFundFlag>
    </ShareClass>
  </AssetDetails>
  <Classifications>
    <Classification>
      <ListedGroup>MORNINGSTAR</ListedGroup>
      <Type>Global Category</Type>
      <Language>en</Language>
      <Value>Europe Large-Cap Blend Equity</Value>
    </Classification>
  </Classifications>
</Asset>

Three points about this example. First, the <ShareClass> child at the position level carries <Shares> (the number of fund units held, xs:decimal), <Price> (the last NAV of the held share class, in its native currency), and <PurchaseValue> (the historical cost). Unlike <Equity>, the share-class inner block has no <MarketValue> field — the consolidated value of the position lives at the <Position>/<TotalValue> level, not inside <ShareClass>. A producer that wants to carry the held fund's own NAV-times-units figure for debugging purposes can do so in <OtherPrices>.

Second, the asset entry marks the held fund as an ETF through <ExchangeTradedFundFlag>true</ExchangeTradedFundFlag> inside <AssetDetails>/<ShareClass> — a dedicated boolean that is in addition to the generic Listing enumeration. Consumers that want to identify ETFs read the flag directly rather than parsing the MIC code or the listing status. The <Classifications> block carries the Morningstar global category — a real Morningstar label that Europe-large-cap blend ETFs actually occupy — through the idiomatic <ListedGroup>MORNINGSTAR</ListedGroup> path.

Third, the holding fund's own cost disclosure under MiFID II does need to aggregate the held ETF's ongoing charges on a proportional basis, but the mechanism is not through a field on the share-class instrument. The aggregation happens in the regulatory templates of Chapter 8, where the EMT provides its own per-instrument cost structure and the consumer rolls them up. For the purposes of the portfolio block, the held ETF is just another position valued at its current NAV.

---

6.9 Derivatives

Derivatives are the most conceptually complex asset class in FundsXML, and they deserve the pages they are about to receive. For the Europa Growth Fund, derivatives appear in a single place: the two currency forwards that implement the CHF hedge for the R-CHF-ACC-HEDGED share class from Chapter 5. Other funds hold futures, options, and swaps in much larger proportions, and the general framework this section establishes applies to all of them.

6.9.1 Notional versus Market Value — the Key Concept

Derivatives differ from every other asset class because they have two value figures, and the figures can differ by orders of magnitude.

Notional is the economic exposure of the contract — the amount on which the contract's payoffs are based. A currency forward to buy 59 million CHF and sell 56.7 million EUR at a rate of 1.0420 has a notional of 56.7 million EUR on the sell side and 59 million CHF on the buy side — two valid representations of the same contract, related by the agreed forward rate. A futures contract on 10,000 units of a DAX index future has a notional equal to the index level times the contract multiplier times 10,000. A swap has a notional equal to the principal on which the periodic payments are computed.

Market value (also called fair value) is the present value of the contract itself as a tradable instrument — the amount a market participant would pay today to take the contract off the fund's hands. When a contract is first entered into, its market value is zero (because both parties agreed it was fair). As the underlying moves, the market value moves away from zero: a currency forward to sell EUR becomes valuable to the seller if the EUR weakens against the bought currency, and worthless or negative if the EUR strengthens. The absolute value of the market value is typically tiny compared to the notional — perhaps one-hundredth to one-thousandth of it, depending on the time remaining to expiry and the volatility of the underlying.

The difference matters enormously. The Europa Growth Fund's CHF hedge forwards have notional amounts in the tens of millions of euros but market values in the hundreds of thousands or less. A consumer that reads the notional and treats it as the position's contribution to market value will overstate the fund's portfolio by tens of millions of euros, and the fund's NAV calculation will be impossible to reconcile.

Where the two numbers live in FundsXML. The schema does not have dedicated Notional and MarketValue fields at the position level — this is the single most important difference from the generic derivative model a newcomer might expect. Instead:

• The fair value of the contract, in the fund's base currency, lives in the position's mandatory <TotalValue> element (schema type FundAmountType, at the top of <Position>, as for every other asset class). For an FX forward, TotalValue is the mark-to-market of the contract, and can be positive or negative depending on whether the trade is in or out of the money.
• The notional amounts live on the asset side, inside AssetDetails/<FXForward>/<AmountBuy> and <AmountSell>, paired with the two currencies (CurrencyBuy and CurrencySell). These are the contractual quantities of each currency, not valuations — they do not change over the life of the contract, while TotalValue moves with the spot rate.
• An optional <Exposures> container at the position level (schema type ExposureType) carries additional exposure figures computed under specific regulatory methodologies — the AIFMD commitment approach, the gross commitment approach, a custom producer method — each as a labelled <Exposure> entry with its own amount. This is the field producers populate when they need to carry a notional-style exposure figure explicitly rather than leaving it implicit in the asset-side AmountSell.

The discipline is therefore subtly different from the "Notional vs MarketValue" framing one finds in textbook descriptions. A consumer reads <TotalValue> for the mark-to-market contribution to the fund's NAV, reads the asset-side AmountBuy/AmountSell for the contractual notional amounts, and reads <Exposures>/<Exposure> for any regulatory exposure figure the producer chose to publish. Substituting one for another is still a catastrophic error — it is just that the labels the schema uses are different from the ones the textbook story suggests.

Table 6.5 — Key derivative-related fields, where they live

Purpose	Field location	Type
Mark-to-market in fund currency	Position/TotalValue	FundAmountType
Regulatory exposure	Position/Exposures/Exposure	labelled Type+Value
Asset-class discriminator	Asset/AssetType	2-char: FX/OP/FU/SW
Position-side sub-block	Position/FXForward | /Option | /Future | /Swap	inline type
Contract details	Asset/AssetDetails/FXForward | /Option | /Future | /Swap	FXForward carries ForeignExchangeTradeType
Contract currencies and notionals (FX)	AssetDetails/FXForward/CurrencyBuy + AmountBuy + CurrencySell + AmountSell	decimal + ISO currency
Agreed forward rate (FX)	AssetDetails/FXForward/AgreedFxRate	xs:decimal
Maturity (FX)	AssetDetails/FXForward/MaturityDate	xs:date (mandatory)
Counterparty	AssetDetails/FXForward/Counterparty	CompanyType (mandatory for FX, must have LEI)
Strike (options)	AssetDetails/Option/StrikePrice	xs:decimal
Contract size (futures, options)	AssetDetails/Future/ContractSize / AssetDetails/Option/ContractSize	xs:decimal

6.9.2 FX Forwards

The derivative type the Europa Growth Fund actually holds, and the simplest class of all.

A currency forward is a contract to exchange a fixed amount of one currency for a fixed amount of another currency at a specific date in the future, at a rate agreed when the contract was entered into. In FundsXML, an FX forward is modelled as AssetType=FX, and the contract details live in AssetDetails/<FXForward>, which is an element of schema type ForeignExchangeTradeType (XSD §25529). Its mandatory children, in order, are:

• <CurrencyBuy> — the currency the fund is contractually buying (ISO 4217 code). An optional @isBaseCCY boolean attribute flags this as the fund's base currency.
• <AmountBuy> — the amount in the buy currency, as a plain xs:decimal. Note that this is not an <Amount ccy="..."> wrapper; it is a bare decimal, with the currency given by the sibling <CurrencyBuy> element. This is a deliberate asymmetry with the position-side amounts, driven by the schema's choice to model the FX trade as a contract rather than a valuation.
• <CurrencySell> — the currency the fund is contractually selling.
• <AmountSell> — the amount in the sell currency, again as a plain xs:decimal.
• <AgreedFxRate> — the forward rate agreed at trade time, as a decimal (e.g. 1.0420 for EUR/CHF at 1.0420 Swiss francs per euro).
• <StartDate> (optional) — the trade date.
• <MaturityDate> — the value date / settlement date. Mandatory; this is the date on which the actual currency exchange takes place.
• <Counterparty> — a CompanyType block naming the bank on the other side of the trade, with its LEI inside <Identifiers>. Mandatory; every FX forward in FundsXML must name its counterparty.
• <Deliverable> (optional, xs:boolean) — whether the currencies will be physically exchanged at maturity (true) or only the profit/loss will be transferred (false, a non-deliverable forward or NDF).

The notional of an FX forward is thus two amounts, not one: the AmountBuy and the AmountSell. Producers pick whichever side corresponds to the fund's base currency as the "economic" notional and ignore the other; for a CHF-hedge forward on a EUR-base fund, the EUR-side AmountSell (the amount the fund has committed to sell) is the operational notional.

The market value of an FX forward at any time between trade and maturity is a function of the current spot rate and the agreed forward rate: when the current rate is favourable to the fund's side of the trade, the value is positive; when unfavourable, it is negative. The producer computes the mark-to-market using standard present-value techniques and writes the result into the position's <TotalValue> in the fund's base currency. Consumers do not attempt to recompute.

The position-side <FXForward> sub-block carries almost no content. The only fields it defines are <HedgeRatio> (an optional PercentageType stating how much of the target exposure the forward covers) and <FxRateForEvaluation> (an optional xs:decimal with the spot rate used for today's valuation). Everything else — the currencies, the amounts, the maturity, the counterparty — lives on the asset side. The reason is that the same contract is usually described once per delivery in AssetMasterData and may be held by several funds in the same file; the per-position data is only the fund-specific hedge ratio and today's valuation.

The Europa Growth Fund's CHF hedge consists of one or two overlapping forward contracts at any time: a currently-active forward that was rolled from the previous month and is due to settle at the end of the current month, and sometimes a just-entered forward for the next period. The structure is simple: approximately 56.7 million EUR (equal to the EUR equivalent of the R-CHF-ACC-HEDGED class's total net assets from §5.12) is sold forward against CHF at a forward rate close to the current spot. The forward is rolled at the end of each month, closing out the old contract and opening a new one.

6.9.3 Futures, Options, and Swaps

The remaining derivative types appear more briefly because they are not held by the Europa Growth Fund. Each gets a short paragraph naming its distinguishing fields.

Futures (AssetType=FU, asset-side details in AssetDetails/<Future> with schema type FutureType) are standardised, exchange-listed derivative contracts. Unlike forwards, they are margined daily — the fund pays or receives a cash amount each day equal to the change in the contract's mark-to-market value, so the position's <TotalValue> is conventionally zero or close to it (yesterday's margin movement has already moved into the cash balance). The FutureType fields that matter are <Type> (an enumeration covering BF Bond Future, CF Currency Future, EF Equity Future, FRA Forward Rate Agreement, IF Index Future, IRF Interest Rate Future, MMF Money Market Future, and OTHER), <ContractSize>, <MaturityDate>, and <BasePrice>. The position-side <Future> sub-block carries <Contracts> (the number of contracts, which may be negative for a short position) and a few supporting fields.

Options (AssetType=OP, asset-side details in AssetDetails/<Option> with schema type OptionType) carry additional fields because they are asymmetric contracts. OptionType/<Type> distinguishes the option family through a twelve-value enumeration: BFO Bond Future Option, BO Bond Option, CFO Currency Future Option, EFO Equity Future Option, CO Currency Option, IFO Index Future Option, IO Index Option, IRFO Interest Rate Future Option, IRO Interest Rate Option, OTCIB OTC Index-basket Option, SO Stock Option, OTHER. Strike price lives in OptionType/<StrikePrice>, contract size in <ContractSize>, expiry in <MaturityDate>, the call/put distinction in <CallPutIndicator> (C or P), and the exercise style in <ExecutionStyle> (American or European). The position-side <Option> sub-block carries <Contracts> (negative for a written option) and <Price> (the option premium). The market value of a long option is its premium times the number of contracts; the notional is the strike times the contract size times the number of contracts. A short option contributes the premium negatively.

Swaps (AssetType=SW, asset-side details in AssetDetails/<Swap> with schema type SwapType) are a family rather than a single type. SwapType/<Type> is an enumeration that covers Currencyswap, Crosscurrencyswap, Creditdefaultswap, Indexswap, Totalreturnswap, Assetswap, Commodityswap, Interestrateswap, Inflationswap, and Other. The rest of SwapType carries the shared metadata — StartDate, MaturityDate, SettlementDate, Counterparty, FXRate, AgreedFxRate — and the per-leg detail lives in a <Legs> container holding one or more <Leg> entries with their own rate, reference index, and payment-schedule fields. The position-side <Swap> sub-block carries <HedgeRatio>, <CurrentSpread> (relevant for Credit Default Swaps), <PresentValueOfPayments>, and a <LegValues> container with one entry per leg showing the current valuation of each side as <Type>BUY</Type> or <Type>SELL</Type> plus <Value>. For most European equity UCITS readers this chapter's treatment is enough; specialised bond and macro funds will need the detailed derivative documentation referenced in Appendix E.

6.9.4 FX Forward Example

The active CHF hedge forward of the Europa Growth Fund on 31 March 2026, as it would appear in the portfolio block and the asset master data block.

<!-- Portfolio position -->
<Position>
  <UniqueID>EGF-FXF-20260430-001</UniqueID>
  <Currency>EUR</Currency>
  <TotalValue>
    <Amount ccy="EUR" isFundCcy="true">-142318.50</Amount>
  </TotalValue>
  <FXForward>
    <HedgeRatio>100.00</HedgeRatio>
    <FxRateForEvaluation>1.0395</FxRateForEvaluation>
  </FXForward>
</Position>

<!-- Asset entry -->
<Asset>
  <UniqueID>EGF-FXF-20260430-001</UniqueID>
  <Currency>EUR</Currency>
  <Name>EUR/CHF Forward 30/04/2026 (main hedge roll)</Name>
  <AssetType>FX</AssetType>
  <AssetDetails>
    <FXForward>
      <CurrencyBuy>CHF</CurrencyBuy>
      <AmountBuy>59107354.41</AmountBuy>
      <CurrencySell isBaseCCY="true">EUR</CurrencySell>
      <AmountSell>56724871.39</AmountSell>
      <AgreedFxRate>1.0420</AgreedFxRate>
      <StartDate>2026-02-28</StartDate>
      <MaturityDate>2026-04-30</MaturityDate>
      <Counterparty>
        <Identifiers>
          <LEI>O2RNE8IBXP4R0TD8PU41</LEI>
        </Identifiers>
        <Name>Société Générale S.A.</Name>
        <BusinessCountry>FR</BusinessCountry>
        <Type>Deposit-taking corporations except the central bank</Type>
      </Counterparty>
      <Deliverable>true</Deliverable>
    </FXForward>
  </AssetDetails>
</Asset>

Reading field by field: the position has no <Currency> override (the forward is already expressed in the fund's EUR base) and a mandatory <TotalValue> of negative 142,318.50 EUR, because the EUR has strengthened slightly against the CHF since the forward was entered into on 28 February, making the agreed sell rate slightly unfavourable to the fund. The negative sign on the <Amount> value is entirely schema-valid (the underlying xs:decimal type accepts negative values), and it is how the schema represents an out-of-the-money derivative position. Inside <FXForward>, the <HedgeRatio>100.00</HedgeRatio> declares that the forward fully covers its target exposure, and <FxRateForEvaluation>1.0395</FxRateForEvaluation> is the spot rate the producer used for today's mark-to-market.

The asset entry identifies the contract as an FX forward through <AssetType>FX</AssetType> and places the contract details inside <AssetDetails>/<FXForward>. The buy side is 59,107,354.41 CHF; the sell side is 56,724,871.39 EUR with @isBaseCCY="true" flagging it as the fund base currency; and the agreed forward rate is 1.0420 (close to the then-prevailing spot). <MaturityDate> is the settlement date on which the currencies will actually be exchanged (30 April 2026, one month out from the valuation point). The <Counterparty> is a full CompanyType block — the schema refuses anything less — with Société Générale's LEI inside <Identifiers> and the ECB sector classification identifying it as a deposit-taking corporation. The <Deliverable>true</Deliverable> flag declares that this is a standard deliverable forward, not a non-deliverable forward with cash settlement.

The UniqueID is a producer-generated string (EGF-FXF-20260430-001) rather than an ISIN, because over-the-counter forwards have no ISIN. The format is conventional: the fund short code, the instrument type, the maturity date, and a sequence number. Because xs:ID demands that the value begin with a letter, the EGF- prefix is mandatory; a raw numeric code would not pass schema validation.

The linkage to Chapter 5 is worth making explicit. The R-CHF-ACC-HEDGED share class from §5.10.2 carries <CurrencyHedgedFlag>true</CurrencyHedgedFlag>. That flag is the declaration that the class is currency-hedged; this forward is the operational mechanism by which the hedge is implemented. Without the forward, the CHF class would be exposed to EUR/CHF movements; with the forward, those movements are neutralised (imperfectly — the hedge cost absorbs into NAV, as §5.10.2 warned). The −142,318.50 EUR <TotalValue> is exactly the kind of small mark-to-market movement that gets absorbed into the CHF class's daily NAV.

---

6.10 Cash, Real Estate, and Other Asset Classes

The catchment section for everything that is neither equity, bond, fund, nor derivative. Three subsections of unequal importance.

6.10.1 Cash Positions

Cash is operationally the simplest asset class but deserves a careful discussion because FundsXML models it through a choice of three distinct asset-type codes, and picking the right one is the first decision.

Three asset-type codes for cash. The schema distinguishes:

• AC — Account: an ordinary bank account the fund maintains with its custodian. Details live in AssetDetails/<Account> (schema type AccountType, XSD §68). This is the most common cash asset class and covers current accounts, nostro accounts, and cash management accounts.
• FT — Fixed Time Deposit: a fixed-term deposit, typically thirty or ninety days, earning a rate above the current-account rate. Details live in AssetDetails/<FixedTimeDeposit> with schema type FixedTimeDepositType, which adds StartDate, MaturityDate, MethodForCalculationOfInterest, and InterestRate fields on top of the counterparty block.
• CM — Call Money: a short-term call money or call capital position, possibly used as collateral. Details live in AssetDetails/<CallMoney> with schema type CallCapitalType, which adds fields for CollateralFlag (whether the cash is pledged) and CollateralDirection (PAID or RECEIVED).

The generic CurrentAccount / TimeDeposit / CashCollateral trio one sees in textbook descriptions is therefore expressed through three separate asset-type codes, not through a single CashType enumeration on a single asset. A producer picks the code that best fits the account's operational nature and populates the corresponding details block.

The AccountType details block is the one most fund administrators actually use, and its children are minimal: an optional <IndicatorCreditDebit> (Credit or Debit) naming the account's default balance direction, optional <AccountNumber> and <IBAN> for regulatory reporting, optional <InterestRateDebit> and <InterestRateCredit> for overdraft and credit rates, and a mandatory <Counterparty> block of type CompanyType identifying the bank holding the account.

One position per currency. A fund with positions in EUR, GBP, and CHF has three cash positions, each representing one currency balance, each with its own <Asset> entry. There is no mechanism for aggregating multi-currency cash into a single position; the model forces the producer to name each currency explicitly. The position's <Currency> element and the asset's top-level <Currency> element must agree.

Counterparty and concentration limits. The bank holding the cash matters operationally because concentration limits under UCITS and AIFMD are applied against the counterparty, not the currency; a fund that holds 50 million EUR at a single bank has a 50 million EUR concentration against that bank, regardless of what other banks it also uses. For a custodian-held account the counterparty is the custodian itself; for cash collateral it is whichever party holds the collateral account (often a different bank). The counterparty's LEI is the single most important field on the whole cash asset entry.

Position-side fields. At the position level, a cash entry ends with an <Account> child (or <FixedTimeDeposit>, <CallMoney> for the other types). The <Account> inner block is the simplest of all choice children: both its children are optional — an <MarketValue> (the current balance, in the account's currency) and an <Interests> (accrued interest not yet credited). In practice producers populate <MarketValue> because it carries the operational balance, but the schema does not insist. There is no <Units>, no <Shares>, no <Contracts> — cash has no unit count, only a balance — and the authoritative fund-currency value lives at the position's <TotalValue> as always.

Example: the Europa Growth Fund's primary EUR cash position at its Luxembourg custodian on 31 March 2026.

<!-- Portfolio position -->
<Position>
  <UniqueID>EGF-CASH-EUR-001</UniqueID>
  <Currency>EUR</Currency>
  <TotalValue>
    <Amount ccy="EUR" isFundCcy="true">3247819.45</Amount>
  </TotalValue>
  <TotalPercentage>0.70</TotalPercentage>
  <Account>
    <MarketValue>
      <Amount ccy="EUR" isFundCcy="true">3247819.45</Amount>
    </MarketValue>
  </Account>
</Position>

<!-- Asset entry -->
<Asset>
  <UniqueID>EGF-CASH-EUR-001</UniqueID>
  <Currency>EUR</Currency>
  <Country>LU</Country>
  <Name>EUR Current Account — BGL BNP Paribas</Name>
  <AssetType>AC</AssetType>
  <AssetDetails>
    <Account>
      <IndicatorCreditDebit>Credit</IndicatorCreditDebit>
      <InterestRateCredit>0.15</InterestRateCredit>
      <Counterparty>
        <Identifiers>
          <LEI>549300CL2K1QUOZK7T97</LEI>
        </Identifiers>
        <Name>BGL BNP Paribas S.A.</Name>
        <BusinessCountry>LU</BusinessCountry>
        <Type>Deposit-taking corporations except the central bank</Type>
      </Counterparty>
    </Account>
  </AssetDetails>
</Asset>

Reading this pair: the position says the fund holds a euro current-account balance of 3.25 million euros at its Luxembourg custodian, representing 0.70% of total net assets. The <Account> inner block at the position level carries only the same balance as the position's consolidated <TotalValue> — for cash, the two are identical by construction, and the apparent redundancy is a schema artefact. The asset entry uses <AssetType>AC</AssetType> to signal Account, places the counterparty block inside <AssetDetails>/<Account> as the schema requires, and populates the counterparty's LEI (the critical field for concentration-limit reporting) inside <Identifiers> following the CompanyType convention. An optional <InterestRateCredit> of 0.15% indicates the rate the custodian is currently paying on the credit balance.

The Europa Growth Fund also holds small balances in GBP (from sterling dividend receipts on UK-listed holdings) and in CHF (for the CHF-hedge operational account). Both follow the same pattern, each as its own position with its own asset entry, both held at the same BGL BNP Paribas custodian.

6.10.2 Real Estate

The Europa Growth Fund holds no real estate, and this chapter does not attempt a detailed treatment. The structural essentials are worth naming briefly so that a reader who one day meets a real-estate fund delivery recognises the pattern.

Real estate comes in two forms. Indirect real estate — shares in listed REITs, units in property funds, private real-estate vehicles — is modelled through the ordinary EQ or SC asset types; the "real estate" nature shows up in the issuer's business and in classifications, not in a new asset class. Direct real estate — the fund owns the physical building — is modelled through AssetType=RE with AssetDetails/<RealEstate>, which carries property-specific fields for location, valuation method, and occupancy. Open-ended German and Luxembourg property funds are the usual populators of this branch; the schema's RealEstateType runs to several pages and its detail is outside the scope of this chapter. Readers interested in real-estate-specific reporting should consult the specialised documentation referenced in Appendix E.

6.10.3 Commodities, Private Equity, and Alternatives

A short catch-all for asset classes that do not appear in the Europa Growth Fund and are not treated in detail in this chapter. The schema has dedicated types for each:

• Commodities — AssetType=CO, details in AssetDetails/<Commodity>. Physical commodities are effectively excluded from UCITS portfolios by eligibility rules; they appear in specialised AIFs. Commodity futures are derivatives (§6.9), commodity-linked structured notes are bonds (§6.7).
• Private equity — AssetType=PE, details in AssetDetails/<PrivateEquity>. Holdings in non-listed companies, typically held through a limited partnership structure. Valued by mark-to-model rather than by market quote, updated quarterly or semi-annually. AIF territory.
• Hedge funds use AssetType=SC (share class, like any other fund) but with additional operational complications around redemption gates, lock-up periods, and side pockets that the position-level schema does not model directly. Producers extend through <CustomAttributes>.
• Rights, warrants, certificates, crypto — AssetType=RI/WA/CE/CR respectively, each with a dedicated details block in AssetDetailsType.

None of these asset classes appears in the Europa Growth Fund's portfolio, and none appears in the complete example of §6.12. They are named for completeness and for the reader who one day encounters an AIF delivery and needs to know that the mechanism exists — the branch in AssetDetailsType is already there, waiting for the asset.

---

6.11 Portfolio Breakdowns by Dimension

We close Part III of the chapter with a topic that sits alongside positions rather than inside them: the pre-computed aggregates that FundsXML delivers in its <BreakDowns> element. The capitalisation is deliberate — the element name is BreakDowns with a capital D, the container is a child of Portfolio (not of FundDynamicData or a separate root), and the structure is surprisingly more flexible than most readers expect.

6.11.1 Why Breakdowns Exist

A portfolio with 150 positions can be sliced along many dimensions — by sector, by country, by currency, by rating, by maturity, by instrument type. A consumer that wants to render a sector chart on a factsheet does not want to re-aggregate 150 position records every time the factsheet regenerates; it wants a ready-made list of "Healthcare 17.50%, Financials 17.20%, Industrials 14.40%, …". The <BreakDowns> element carries exactly this: pre-computed slices of the portfolio along standard dimensions, each containing a list of buckets with labels and percentages.

Two more substantive reasons justify the pre-computation. First, classification conventions are producer-specific. Two consumers that re-aggregate the same 150 positions may apply different sector classifications (GICS vs ICB), different country assignments (country of issue vs country of risk), or different lookthrough rules for held funds. The producer, being the single authoritative source, emits one classification, and every consumer using the producer's breakdowns sees the same picture. Consumers that want a different classification can still re-aggregate themselves, but the default is to trust the producer.

Second, some breakdowns cannot be re-computed from positions alone. A fund's currency breakdown, if it takes hedging into account, cannot be derived from the position-level currency fields alone — it requires knowledge of which forwards hedge which exposures, and the producer computes the net result after applying the hedges. A consumer recomputing from raw positions would get a pre-hedge exposure, which is not what the factsheet shows.

6.11.2 Structure of a Breakdown

The schema type is BreakDownsType (XSD §2390), and it is multi-dimensional by design. A single <BreakDowns> element contains one or more <BreakDown> children; each <BreakDown> carries:

• A <Dimensions> container holding one or more <Dimension> strings naming the dimensions along which the breakdown slices the portfolio. Common values are Sector, Country, Currency, Rating, Duration, AssetType, Region, Size. A single <Dimension> gives a one-dimensional breakdown; two <Dimension> entries (Currency and AssetType) produce a two-dimensional cross-tabulation.
• An optional <CalculationMethod> free-text field naming the basis of the calculation (Market Value, Exposure, Brutto, Netto, and so on).
• A mandatory <Values> container holding one or more <Value> entries. Each <Value> is one cell of the breakdown table and carries:
• A <DimValues> container with one <DimValue> per dimension, each labelled by a @dim attribute identifying which dimension the value belongs to. For a one-dimensional sector breakdown, each <Value> has one <DimValue dim="Sector">Financials</DimValue> element; for a two-dimensional breakdown, each <Value> has two <DimValue> elements, one per dimension.
• A mandatory <Percentage> (PercentageType, in per cent) giving the cell's share of the portfolio, from 0 to 100.
• An optional nested <BreakDowns> element, allowing a breakdown cell to carry its own sub-breakdowns — the structure is recursive. A Financials sector cell, for example, can carry an inner breakdown into Banks, Insurance, Diversified Financials, each with its own percentage relative to the parent cell's share of the portfolio.

The completeness rule is that the sum of percentages across all <Value> entries within a single <BreakDown> should equal 100, subject to a rounding tolerance of a few basis points. A breakdown that sums to 99.95% or 100.03% is acceptable; a breakdown that sums to 92% is missing a cell and is a data-quality issue.

A concrete example — a one-dimensional sector breakdown for a generic European equity fund, shortened to four cells:

<BreakDowns>
  <BreakDown>
    <Dimensions>
      <Dimension>Sector</Dimension>
    </Dimensions>
    <CalculationMethod>Market Value</CalculationMethod>
    <Values>
      <Value>
        <DimValues>
          <DimValue dim="Sector">Financials</DimValue>
        </DimValues>
        <Percentage>22.50</Percentage>
      </Value>
      <Value>
        <DimValues>
          <DimValue dim="Sector">Industrials</DimValue>
        </DimValues>
        <Percentage>18.75</Percentage>
      </Value>
      <Value>
        <DimValues>
          <DimValue dim="Sector">Consumer Discretionary</DimValue>
        </DimValues>
        <Percentage>15.20</Percentage>
      </Value>
      <Value>
        <DimValues>
          <DimValue dim="Sector">Healthcare</DimValue>
        </DimValues>
        <Percentage>14.15</Percentage>
      </Value>
      <!-- further cells elided -->
    </Values>
  </BreakDown>
</BreakDowns>

A producer typically emits several <BreakDown> entries inside one <BreakDowns> container — one for each dimension the fund's consumers need. The Europa Growth Fund's monthly delivery emits breakdowns by sector, country, and currency at a minimum, and its complete <BreakDowns> block in §6.12 shows all three as sibling <BreakDown> entries.

Two-dimensional breakdowns. The multi-dimensional design shines when a consumer needs a cross-tabulation. A <BreakDown> with two <Dimension> children (Country and Sector) has one <Value> per country-sector cell, each with two <DimValue> elements carrying the two labels. The German Financials cell, the French Industrials cell, the Swiss Healthcare cell, and so on — each appears as a separate <Value> entry with its own percentage. This flexibility is largely unused in current production pipelines because most consumers prefer simpler one-dimensional breakdowns, but it is there when the need arises.

6.11.3 The Common Breakdown Types in Practice

Sector breakdown uses GICS by default for European equity funds, ICB for some British contexts, NACE for regulatory reporting. A diversified European equity fund typically shows Financials, Industrials, Consumer Discretionary, Healthcare, Technology, and Consumer Staples as the five or six largest sectors, each in the 10% to 25% range, followed by Utilities, Energy, Materials, Real Estate, and Communication Services in smaller allocations. The precise weights shift with the benchmark and the manager's active bets.

Country breakdown is based on the issuer's country of domicile (for equities) or country of risk (for bonds). A typical European equity fund is weighted heavily toward France and Germany — together 40% to 50% — with Switzerland, the Netherlands, Spain, Italy, and Scandinavia filling the remainder. The Europa Growth Fund's breakdown in §6.12 will show exactly this pattern.

Currency breakdown shows the currencies in which the portfolio is denominated, typically before hedging effects. For a European equity fund the dominant currency is EUR, with CHF (Swiss stocks), GBP (UK stocks), and smaller allocations to DKK, NOK, and SEK from Nordic holdings.

Rating breakdown matters for bond portfolios and is largely irrelevant for pure equity funds. The standard cells are AAA, AA+ through AA-, A+ through A-, BBB+ through BBB-, BB and below, Not Rated. The producer picks a convention for which agency's rating to use (typically the middle of the three main agencies, or the lowest for conservatism).

Duration breakdown likewise matters for bonds. Cells are typically 0–1 year, 1–3 years, 3–5 years, 5–10 years, 10–20 years, 20+ years, or a shorter set for short-duration funds. The dimension name in the schema is Duration, and the convention is to put the same bucket labels that the factsheet uses into the <DimValue dim="Duration"> elements. Equity funds do not emit duration breakdowns.

6.11.4 Producer versus Consumer Computation

A consumer that re-computes breakdowns from the raw positions will often find small differences from the producer's figures. Three sources account for almost all of the differences.

Rounding. Position-level percentages are rounded to two decimal places; summing rounded values gives a total that can differ from the producer's figure (which was computed at full precision before rounding) by a few basis points. This is an artefact of rounding, not a data error.

Classification ambiguity. A company like Siemens is both an industrial conglomerate and a technology provider, and different classification schemes place it differently. The producer's breakdown reflects the producer's chosen classification; a consumer using its own classification library will get different numbers. Neither is wrong; they are answers to slightly different questions.

Lookthrough. When the fund holds another fund (§6.8) and the producer has populated <PositionsDecomposed> to apply lookthrough to the held fund's underlying holdings, the producer's sector breakdown is computed from the decomposed positions and reflects the underlying holdings rather than the held fund as a single Fund cell. A consumer that reads <Positions> directly but reads the producer's breakdown will see a different picture than one that re-aggregates <Positions> itself. The difference is the lookthrough effect.

The operational rule is straightforward: consumers trust the producer's breakdowns and recompute only for validation purposes, with appropriate tolerance. Chapter 10 will formalise the tolerances that production validators should apply to breakdown reconciliation.

---

6.12 The Complete Europa Growth Fund Portfolio

We are now ready to assemble the largest example in the book. The Europa Growth Fund on 31 March 2026 holds approximately 150 distinct positions: 145 European equity positions across eleven countries and eleven sectors, three cash positions (EUR, GBP, CHF), and two currency forwards implementing the CHF hedge. The complete portfolio appears in Appendix D; this section shows a representative sample of fifteen equity positions, the three cash positions, and the two forwards, together with their AssetMasterData entries and the resulting portfolio breakdowns.

6.12.1 The Real Portfolio

Before looking at the XML, a word on what the real portfolio looks like. The fund's 145 equity positions are not uniform in size; the largest ten or so positions account for thirty to forty percent of the portfolio (the manager's conviction picks), while the remaining 130-plus positions form a long tail of smaller holdings for diversification. The sample of fifteen positions shown below is drawn from the larger end of the portfolio, so that each position is meaningful in size (between five and fifteen million euros), and is distributed across sectors and countries so that the portfolio breakdowns at the end of the section are meaningful.

The combined market value of the fifteen sample positions plus the three cash positions comes to approximately 130 million EUR — roughly 28% of the fund's total net assets of 464.55 million EUR. The remaining 72% lives in the 130 positions that are not shown here. The currency forwards do not add materially to the portfolio market value (their market values are in the low hundreds of thousands, positive or negative, absorbed into the hedged class's NAV).

6.12.2 The Portfolio Block

<Portfolio>
  <NavDate>2026-03-31</NavDate>
  <Positions>
    <!-- Equity positions (fifteen representative entries) -->
    <Position>
      <UniqueID>DE0007236101</UniqueID>
      <Currency>EUR</Currency>
      <TotalValue><Amount ccy="EUR" isFundCcy="true">8125000.00</Amount></TotalValue>
      <TotalPercentage>1.75</TotalPercentage>
      <PriceDate>2026-03-31</PriceDate>
      <Equity>
        <Units>50000</Units>
        <Price><Amount ccy="EUR">162.50</Amount></Price>
        <MarketValue><Amount ccy="EUR" isFundCcy="true">8125000.00</Amount></MarketValue>
      </Equity>
    </Position>
    <Position>
      <UniqueID>DE0007164600</UniqueID>
      <Currency>EUR</Currency>
      <TotalValue><Amount ccy="EUR" isFundCcy="true">8538000.00</Amount></TotalValue>
      <TotalPercentage>1.84</TotalPercentage>
      <PriceDate>2026-03-31</PriceDate>
      <Equity>
        <Units>60000</Units>
        <Price><Amount ccy="EUR">142.30</Amount></Price>
        <MarketValue><Amount ccy="EUR" isFundCcy="true">8538000.00</Amount></MarketValue>
      </Equity>
    </Position>
    <Position>
      <UniqueID>DE0008404005</UniqueID>
      <Currency>EUR</Currency>
      <TotalValue><Amount ccy="EUR" isFundCcy="true">7964800.00</Amount></TotalValue>
      <TotalPercentage>1.72</TotalPercentage>
      <PriceDate>2026-03-31</PriceDate>
      <Equity>
        <Units>32000</Units>
        <Price><Amount ccy="EUR">248.90</Amount></Price>
        <MarketValue><Amount ccy="EUR" isFundCcy="true">7964800.00</Amount></MarketValue>
      </Equity>
    </Position>
    <!-- LVMH, TotalEnergies, BNP Paribas (FR) and Nestlé, Roche, Novartis (CH)
         follow the same pattern; the three Swiss positions carry their prices in
         CHF and their TotalValue in EUR (isFundCcy="true") alongside a CHF-native
         Amount for transparency -->
    <Position>
      <UniqueID>CH0038863350</UniqueID>
      <Currency>CHF</Currency>
      <TotalValue>
        <Amount ccy="EUR" isFundCcy="true">6017500.00</Amount>
        <Amount ccy="CHF">6270290.00</Amount>
      </TotalValue>
      <TotalPercentage>1.30</TotalPercentage>
      <PriceDate>2026-03-31</PriceDate>
      <Equity>
        <Units>65000</Units>
        <Price><Amount ccy="CHF">96.40</Amount></Price>
        <MarketValue>
          <Amount ccy="EUR" isFundCcy="true">6017500.00</Amount>
          <Amount ccy="CHF">6270290.00</Amount>
        </MarketValue>
      </Equity>
    </Position>
    <!-- ASML (NL), Shell, Unilever, AstraZeneca (GB), Iberdrola, Banco Santander (ES)
         follow the pattern. Cash positions come next. -->

    <!-- Cash accounts (one position per currency) -->
    <Position>
      <UniqueID>EGF-CASH-EUR-001</UniqueID>
      <Currency>EUR</Currency>
      <TotalValue><Amount ccy="EUR" isFundCcy="true">3247819.45</Amount></TotalValue>
      <TotalPercentage>0.70</TotalPercentage>
      <Account>
        <MarketValue><Amount ccy="EUR" isFundCcy="true">3247819.45</Amount></MarketValue>
      </Account>
    </Position>
    <Position>
      <UniqueID>EGF-CASH-GBP-001</UniqueID>
      <Currency>GBP</Currency>
      <TotalValue><Amount ccy="EUR" isFundCcy="true">208541.30</Amount></TotalValue>
      <TotalPercentage>0.04</TotalPercentage>
      <Account>
        <MarketValue><Amount ccy="EUR" isFundCcy="true">208541.30</Amount></MarketValue>
      </Account>
    </Position>
    <Position>
      <UniqueID>EGF-CASH-CHF-001</UniqueID>
      <Currency>CHF</Currency>
      <TotalValue><Amount ccy="EUR" isFundCcy="true">156217.80</Amount></TotalValue>
      <TotalPercentage>0.03</TotalPercentage>
      <Account>
        <MarketValue><Amount ccy="EUR" isFundCcy="true">156217.80</Amount></MarketValue>
      </Account>
    </Position>

    <!-- FX forwards implementing the CHF hedge for R-CHF-ACC-HEDGED -->
    <Position>
      <UniqueID>EGF-FXF-20260430-001</UniqueID>
      <Currency>EUR</Currency>
      <TotalValue><Amount ccy="EUR" isFundCcy="true">-142318.50</Amount></TotalValue>
      <FXForward>
        <HedgeRatio>100.00</HedgeRatio>
        <FxRateForEvaluation>1.0395</FxRateForEvaluation>
      </FXForward>
    </Position>
    <Position>
      <UniqueID>EGF-FXF-20260430-002</UniqueID>
      <Currency>EUR</Currency>
      <TotalValue><Amount ccy="EUR" isFundCcy="true">18420.75</Amount></TotalValue>
      <FXForward>
        <HedgeRatio>100.00</HedgeRatio>
        <FxRateForEvaluation>1.0395</FxRateForEvaluation>
      </FXForward>
    </Position>
  </Positions>
  <!-- BreakDowns follow in §6.12.4 -->
</Portfolio>

6.12.3 The AssetMasterData Block (Representative Entries)

At the root level of the document, the AssetMasterData block carries one entry per unique position referenced above. We show three representative entries in full — a German equity, a Swiss equity, and a cash account — together with one FX forward, and list the remainder in summary form.

<AssetMasterData>
  <Asset>
    <UniqueID>DE0007236101</UniqueID>
    <Identifiers>
      <ISIN>DE0007236101</ISIN>
      <GermanWKN>723610</GermanWKN>
    </Identifiers>
    <Currency>EUR</Currency>
    <Country>DE</Country>
    <Name>Siemens AG</Name>
    <AssetType>EQ</AssetType>
    <AssetDetails>
      <Equity>
        <StockMarket>XETR</StockMarket>
        <Issuer>
          <Identifiers><LEI>W38RGI023J3WT1HWRP32</LEI></Identifiers>
          <Name>Siemens Aktiengesellschaft</Name>
          <BusinessCountry>DE</BusinessCountry>
          <Type>Non-financial corporations</Type>
        </Issuer>
        <Listing>A</Listing>
        <CustomMarketCapitalization>
          <Name>Large Cap</Name>
          <Date>2026-03-31</Date>
          <Value>145000000000</Value>
        </CustomMarketCapitalization>
        <Industries>
          <IndustryCode>
            <Name>GICS</Name>
            <Date>2026-03-31</Date>
            <Value>20106010</Value>
          </IndustryCode>
        </Industries>
      </Equity>
    </AssetDetails>
    <Classifications>
      <Classification>
        <UnlistedGroup>GICS</UnlistedGroup>
        <Type>Sector</Type>
        <Language>en</Language>
        <Value level="1">Industrials</Value>
        <Value level="2">Industrial Conglomerates</Value>
      </Classification>
    </Classifications>
  </Asset>

  <Asset>
    <UniqueID>CH0038863350</UniqueID>
    <Identifiers>
      <ISIN>CH0038863350</ISIN>
      <SwissValorenCode>3886335</SwissValorenCode>
    </Identifiers>
    <Currency>CHF</Currency>
    <Country>CH</Country>
    <Name>Nestlé S.A.</Name>
    <AssetType>EQ</AssetType>
    <AssetDetails>
      <Equity>
        <StockMarket>XVTX</StockMarket>
        <Issuer>
          <Identifiers><LEI>549300DLLUD0PKVWST52</LEI></Identifiers>
          <Name>Nestlé S.A.</Name>
          <BusinessCountry>CH</BusinessCountry>
        </Issuer>
      </Equity>
    </AssetDetails>
    <Classifications>
      <Classification>
        <UnlistedGroup>GICS</UnlistedGroup>
        <Type>Sector</Type>
        <Language>en</Language>
        <Value>Consumer Staples</Value>
      </Classification>
    </Classifications>
  </Asset>

  <Asset>
    <UniqueID>EGF-CASH-EUR-001</UniqueID>
    <Currency>EUR</Currency>
    <Country>LU</Country>
    <Name>EUR Current Account — BGL BNP Paribas</Name>
    <AssetType>AC</AssetType>
    <AssetDetails>
      <Account>
        <IndicatorCreditDebit>Credit</IndicatorCreditDebit>
        <InterestRateCredit>0.15</InterestRateCredit>
        <Counterparty>
          <Identifiers><LEI>549300CL2K1QUOZK7T97</LEI></Identifiers>
          <Name>BGL BNP Paribas S.A.</Name>
          <BusinessCountry>LU</BusinessCountry>
          <Type>Deposit-taking corporations except the central bank</Type>
        </Counterparty>
      </Account>
    </AssetDetails>
  </Asset>

  <!-- Remaining equity asset entries (summary): -->
  <!-- SAP SE (DE0007164600, LEI 529900D6BF99LW9F3487, IT, DE, XETR)             -->
  <!-- Allianz SE (DE0008404005, LEI 529900K9B0N5BT694847, Insurance, DE, XETR)  -->
  <!-- LVMH (FR0000121014, LEI 96950065LBWY0APQIM86, Cons. Discr., FR, XPAR)     -->
  <!-- TotalEnergies (FR0000120271, LEI 529900S21EQ1BO4ESM68, Energy, FR, XPAR)  -->
  <!-- BNP Paribas (FR0000131104, LEI R0MUWSFPU8MPRO8K5P83, Financials, FR, XPAR)-->
  <!-- Roche (CH0012032048, LEI 549300D3OHVV27GBHI46, Healthcare, CH, XVTX)      -->
  <!-- Novartis (CH0012005267, LEI 549300D9YI2R72XBBM14, Healthcare, CH, XVTX)   -->
  <!-- ASML (NL0010273215, LEI 724500Y6DUVHQD6OXN27, IT, NL, XAMS)               -->
  <!-- Shell (GB00BP6MXD84, LEI 21380068P1DRHMJ8KU70, Energy, GB, XLON)          -->
  <!-- Unilever (GB00B10RZP78, LEI 549300MKFYEKVRWML317, Cons. Staples, GB, XLON)-->
  <!-- Iberdrola (ES0144580Y14, LEI K2RJR3UR2UQIYOV1YS65, Utilities, ES, XMAD)   -->
  <!-- Santander (ES0113900J37, LEI 5493006QMFDDMYWIAM13, Financials, ES, XMAD)  -->
  <!-- AstraZeneca (GB0009895292, LEI 213800ZCSBQL7LI8DI47, Healthcare, GB, XLON)-->

  <!-- Cash asset entries (summary): -->
  <!-- EGF-CASH-GBP-001 (AC, GBP, custodian BGL BNP Paribas LEI 549300CL2K1QUOZK7T97) -->
  <!-- EGF-CASH-CHF-001 (AC, CHF, custodian BGL BNP Paribas LEI 549300CL2K1QUOZK7T97) -->

  <!-- FX Forward asset entries -->
  <Asset>
    <UniqueID>EGF-FXF-20260430-001</UniqueID>
    <Currency>EUR</Currency>
    <Name>EUR/CHF Forward 30/04/2026 (main hedge roll)</Name>
    <AssetType>FX</AssetType>
    <AssetDetails>
      <FXForward>
        <CurrencyBuy>CHF</CurrencyBuy>
        <AmountBuy>59107354.41</AmountBuy>
        <CurrencySell isBaseCCY="true">EUR</CurrencySell>
        <AmountSell>56724871.39</AmountSell>
        <AgreedFxRate>1.0420</AgreedFxRate>
        <StartDate>2026-02-28</StartDate>
        <MaturityDate>2026-04-30</MaturityDate>
        <Counterparty>
          <Identifiers><LEI>O2RNE8IBXP4R0TD8PU41</LEI></Identifiers>
          <Name>Société Générale S.A.</Name>
          <BusinessCountry>FR</BusinessCountry>
          <Type>Deposit-taking corporations except the central bank</Type>
        </Counterparty>
        <Deliverable>true</Deliverable>
      </FXForward>
    </AssetDetails>
  </Asset>
  <!-- Second FX forward (EGF-FXF-20260430-002) is structurally identical with
       AmountBuy=2918000.00, AmountSell=2800000.00, AgreedFxRate=1.0421,
       StartDate=2026-03-15, same MaturityDate and counterparty. -->
</AssetMasterData>

The elided entries follow the same pattern as the fully-shown ones; each equity entry carries its <Identifiers> block with the ISIN (and where present the GermanWKN or SwissValorenCode), its <Currency>, its <Country>, its <Name>, its AssetType=EQ, and an <AssetDetails>/<Equity> block with the stock market MIC, the issuer's LEI inside a CompanyType block, the listing status, and an optional <CustomMarketCapitalization> size bucket; each cash entry carries its counterparty in <AssetDetails>/<Account>; the second FX forward is structurally identical to the first with different amounts and rates. Appendix D prints the full block with every entry populated.

6.12.4 Portfolio Breakdowns for the Sample

Computed from the fifteen equity positions shown above (scaled to 100% of the equity portion, excluding cash and forwards), three breakdowns are representative. They sit inside the same <Portfolio> element as the positions, as a sibling of <Positions> rather than at the root.

<BreakDowns>
  <BreakDown>
    <Dimensions><Dimension>Sector</Dimension></Dimensions>
    <CalculationMethod>Market Value</CalculationMethod>
    <Values>
      <Value>
        <DimValues><DimValue dim="Sector">Healthcare</DimValue></DimValues>
        <Percentage>17.50</Percentage>
      </Value>
      <Value>
        <DimValues><DimValue dim="Sector">Financials</DimValue></DimValues>
        <Percentage>17.20</Percentage>
      </Value>
      <Value>
        <DimValues><DimValue dim="Sector">Industrials</DimValue></DimValues>
        <Percentage>14.40</Percentage>
      </Value>
      <Value>
        <DimValues><DimValue dim="Sector">Technology</DimValue></DimValues>
        <Percentage>14.30</Percentage>
      </Value>
      <Value>
        <DimValues><DimValue dim="Sector">Consumer Staples</DimValue></DimValues>
        <Percentage>11.90</Percentage>
      </Value>
      <Value>
        <DimValues><DimValue dim="Sector">Consumer Discretionary</DimValue></DimValues>
        <Percentage>9.80</Percentage>
      </Value>
      <Value>
        <DimValues><DimValue dim="Sector">Energy</DimValue></DimValues>
        <Percentage>8.90</Percentage>
      </Value>
      <Value>
        <DimValues><DimValue dim="Sector">Utilities</DimValue></DimValues>
        <Percentage>6.00</Percentage>
      </Value>
    </Values>
  </BreakDown>
  <BreakDown>
    <Dimensions><Dimension>Country</Dimension></Dimensions>
    <CalculationMethod>Market Value</CalculationMethod>
    <Values>
      <Value>
        <DimValues><DimValue dim="Country">GB</DimValue></DimValues>
        <Percentage>24.70</Percentage>
      </Value>
      <Value>
        <DimValues><DimValue dim="Country">FR</DimValue></DimValues>
        <Percentage>20.20</Percentage>
      </Value>
      <Value>
        <DimValues><DimValue dim="Country">DE</DimValue></DimValues>
        <Percentage>19.90</Percentage>
      </Value>
      <Value>
        <DimValues><DimValue dim="Country">CH</DimValue></DimValues>
        <Percentage>13.40</Percentage>
      </Value>
      <Value>
        <DimValues><DimValue dim="Country">ES</DimValue></DimValues>
        <Percentage>12.00</Percentage>
      </Value>
      <Value>
        <DimValues><DimValue dim="Country">NL</DimValue></DimValues>
        <Percentage>9.80</Percentage>
      </Value>
    </Values>
  </BreakDown>
  <BreakDown>
    <Dimensions><Dimension>Currency</Dimension></Dimensions>
    <CalculationMethod>Market Value</CalculationMethod>
    <Values>
      <Value>
        <DimValues><DimValue dim="Currency">EUR</DimValue></DimValues>
        <Percentage>61.90</Percentage>
      </Value>
      <Value>
        <DimValues><DimValue dim="Currency">GBP</DimValue></DimValues>
        <Percentage>24.70</Percentage>
      </Value>
      <Value>
        <DimValues><DimValue dim="Currency">CHF</DimValue></DimValues>
        <Percentage>13.40</Percentage>
      </Value>
    </Values>
  </BreakDown>
</BreakDowns>

The breakdowns above are computed from the fifteen-position sample. The breakdowns for the full 150-position portfolio in Appendix D are somewhat different: the UK weighting, in particular, is far less pronounced in the real portfolio (our sample overweights UK blue chips for illustrative purposes), and the sector distribution is more evenly spread across Financials, Industrials, Consumer, and Healthcare without the healthcare dominance that our sample shows. Note also that the country breakdown uses ISO 3166-1 alpha-2 codes (DE, FR, CH, GB, ES, NL) as DimValue labels — a producer convention that keeps the breakdown language-independent; a factsheet engine that wants to render "Germany" rather than "DE" applies its own localised mapping at display time. The structural lesson is the same either way: a breakdown is a cell-by-cell summary of the portfolio along one or more dimensions, and consumers read it directly rather than re-computing from positions.

6.12.5 A Three-Pass Reading

The example is best understood in three passes, each focusing on one of the asset classes the fund holds.

First pass — equities. Each of the fifteen equity positions follows the pattern of §6.6: a <Position> with mandatory <UniqueID> (the ISIN), optional <Currency> (the instrument's native currency), mandatory <TotalValue> (the consolidated value in the fund's EUR base, flagged isFundCcy="true"), optional <TotalPercentage> (the position's weight), optional <PriceDate>, and a mandatory <Equity> child carrying the per-unit detail fields (<Units>, <Price>, <MarketValue>). The asset entries populate the instrument's identifiers, the <Equity> details block with issuer LEI and stock market, and one or more <Classifications> entries. Three of the fifteen positions are Swiss companies priced in CHF (Nestlé, Roche, Novartis) and three are British companies priced in GBP (Shell, Unilever, AstraZeneca); the remaining nine are priced in EUR. The <TotalValue> on every position is EUR-tagged with isFundCcy="true", with the non-EUR positions carrying a second <Amount> in their native currency for transparency.

Second pass — cash. Three cash positions, one per currency, each with AssetType=AC in the master-data entry and an <Account> child at both the position level and inside AssetDetails. The <Account> inner block at the position level contains only a <MarketValue> (the account balance), and the consolidated <TotalValue> at the position's top level carries the same balance expressed in the fund's base currency. Each cash asset entry names the custodian (BGL BNP Paribas S.A., the Europa Growth Fund's Luxembourg custodian) inside AssetDetails/Account/Counterparty, with the counterparty's LEI embedded in CompanyType/Identifiers. The GBP and CHF balances are small — residues from dividend receipts and hedge-operational needs — while the EUR balance of 3.24 million is the fund's main working cash.

Third pass — derivatives. Two currency forwards implementing the CHF hedge for the R-CHF-ACC-HEDGED share class. Each appears in <Positions> with an almost-empty <FXForward> sub-block (just a <HedgeRatio> and the spot rate used for today's valuation) and a position-level <TotalValue> that is the mark-to-market of the contract in EUR — negative 142,318.50 EUR for the main forward and a small positive 18,420.75 EUR for the secondary forward. The actual contract details — who is buying what from whom, at what rate, for settlement on which date, with whose LEI — live on the asset side under AssetDetails/FXForward. The main forward has an AmountSell of 56.7 million EUR and a matching AmountBuy of 59.1 million CHF at the AgreedFxRate of 1.0420 (matching the EUR-equivalent of the hedged class's total net assets from Chapter 5). The secondary forward is a much smaller residual covering a change in the class's AUM since the last monthly roll, with AmountSell 2.8 million EUR. Together the two forwards represent the hedge that makes the <CurrencyHedgedFlag>true</CurrencyHedgedFlag> on the share class operational, and their TotalValue figures absorb directly into the CHF class's NAV as part of its daily valuation.

The sum of <TotalValue> across the fifteen equities, three cash positions, and two forwards is approximately 116.8 million EUR — roughly 25% of the fund's total net assets of 464.55 million EUR. The remaining 75% lives in the 130 equity positions that our sample does not show, and the complete portfolio in Appendix D reconciles exactly to the 464.55 million EUR figure. The structural lesson remains the same: every position, every asset entry, every breakdown follows the same patterns established in the earlier sections of this chapter, and those patterns scale from fifteen positions to one hundred and fifty without modification.

---

6.13 Common Pitfalls

The following short list captures the mistakes that, in our experience, cause the greatest share of portfolio-related production incidents.

• Schema validation fails at load time because a position references a UniqueID that no asset carries. The parser raises an xs:IDREF error — a schema-validation error, not a business-validation error — and the document does not load at all. This is usually the residue of a pipeline in which the position writer and the asset writer ran out of sync. The fix is to emit positions and assets from the same producer pass and to validate every file against the schema before shipping it; Chapter 10 lists this as the first of the mandatory checks.
• Orphaned <Asset> entries in AssetMasterData. Asset entries appear with no position pointing at them — typically the residue of a position that was removed from the portfolio without a cleanup of the master data. Harmless for consumers (the parser does not complain), but a sign of a sloppy producer; pipelines should clean up orphans before emitting.
• TotalValue is missing on a position. A producer writes the position with <Equity>/<MarketValue> but forgets the position-level <TotalValue>. The file fails schema validation — <TotalValue> is mandatory — and the fund's NAV reconciliation cannot proceed. The fix is to populate <TotalValue> on every position without exception, with the position's consolidated market value in the fund's base currency.
• Bond nominal written as pieces instead of nominal amount. A producer writes <Nominal>1000</Nominal> meaning "one thousand pieces" for a bond whose face value is one million EUR total, when the correct representation is <Nominal>1000000</Nominal>. The resulting Bond/MarketValue (computed as Nominal × Price / 100) is off by a factor of a thousand. The fix is to treat bond <Nominal> as a nominal amount without exception and to verify, on every bond position, that Bond/MarketValue + Bond/InterestClaimGross ≈ Position/TotalValue to within a rounding tolerance.
• Market value amount in the wrong currency. The Nestlé position's price is in CHF, and a careless producer writes <Equity>/<MarketValue> in CHF while leaving the position-level <TotalValue> empty. A consumer that reads <TotalValue> to compute the fund total gets a missing value; a consumer that reads <Equity>/<MarketValue> and adds it to the EUR totals of other positions gets an answer that is wrong by the EUR/CHF rate. The fix is to always populate <TotalValue> with at least one <Amount> in the fund's base currency, tagged isFundCcy="true", and to let the asset-class-specific <MarketValue> carry whichever currency suits the producer's internal accounting.
• FX forward <TotalValue> confused with the notional. A consumer reads the <AmountSell> of 56.7 million EUR from AssetDetails/FXForward and treats it as the forward's contribution to the fund's total net assets. The fund's NAV suddenly appears to be 56 million EUR larger than reality, and reconciliation fails. The fix is to always read <Position>/<TotalValue> for the mark-to-market contribution (which is the small positive or negative mark-to-market value, not the notional) and to use <AmountBuy>/<AmountSell> only for exposure reporting, not for valuation.
• <AssetType> is written as Equity or Bond instead of the two-character code. The schema enforces a two-character enumeration (EQ, BO, SC, FX, AC, …) on <AssetType>, and anything else is a schema-validation failure at load time. Producers migrating from formats with English type names must run a mapping pass before emitting the file.
• Breakdown cell percentages do not sum to 100. A sector breakdown sums to 93% because a cell for Utilities is missing from the <Values> list even though some positions belong there. The consumer sees the breakdown as incomplete and either refuses to render it or renders it with a suspicious gap. The fix is to emit every non-empty cell and to include an "Other" catch-all <Value> for positions that do not fit the standard categories.
• Cash position without a counterparty LEI. A cash asset's AssetDetails/Account/Counterparty is a CompanyType, which requires <Identifiers> before <Name>. A producer that writes <Counterparty><Name>BGL BNP Paribas S.A.</Name></Counterparty> without the <Identifiers>/<LEI> child fails schema validation immediately — Identifiers is mandatory on CompanyType. Even if validation somehow passed, a regulatory consumer could not apply counterparty concentration limits to the position because it cannot identify the counterparty unambiguously. The fix is to populate the counterparty LEI on every cash, derivative, and collateral position without exception.

---

6.14 Key Takeaways

• Portfolio positions and AssetMasterData entries together describe what a fund holds. Positions answer the question how much; asset entries answer what. Neither is complete without the other, and consumers always read the two structures together.
• The linkage between positions and asset entries runs through the UniqueID field, declared xs:ID on the asset side and xs:IDREF on the position side. The pairing is enforced by the parser at load time, not by business validation at a later stage. The value must conform to XML Name syntax (must not begin with a digit), and the recommended convention is ISIN when available, deterministic producer-generated string otherwise, so that the same asset receives the same identifier across consecutive deliveries.
• A <Position> has a fixed head of common children — <UniqueID>, optional <Identifiers>, optional <Currency>, mandatory <TotalValue>, optional <TotalPercentage>, optional cost and FX fields, optional <PriceDate>, optional <PricingSource> — followed by a mandatory choice of exactly one asset-class-specific child from twenty-one options (<Equity>, <Bond>, <ShareClass>, <Warrant>, <Certificate>, <Option>, <Future>, <FXForward>, <Swap>, <Repo>, <FixedTimeDeposit>, <CallMoney>, <Account>, <Fee>, <RealEstate>, <REIT>, <Loan>, <Right>, <Commodity>, <PrivateEquity>, <CommercialPaper>), and optionally a trailing block (<CapitalYieldsTaxClaim>, <InflationaryAdjustment>, <RiskCodes>, <Underlyings>, <CustomAttributes>). The unit count, per-unit price, and market value of the position live inside the chosen asset-class child (for example <Equity>/<Units>, <Bond>/<Nominal>, <ShareClass>/<Shares>, <Option>/<Contracts>), not on the position element itself. There is no element called <Quantity>, and no element called <PositionType> — the complex type PositionType is the XSD name of the type of <Position>, never a tag in the document.
• An <Asset> in <AssetMasterData> has its own fixed sequence — UniqueID, optional Identifiers, optional DataSupplier, mandatory Currency, optional IncomeCurrency, optional Country, mandatory Name, optional FISN, mandatory AssetType (as a two-character code), and optional AssetDetails carrying the asset-class-specific choice. Ratings, Classifications, and CustomAttributes follow at the bottom.
• For bonds, <Bond>/<Nominal> is the nominal value in the issue currency, not the number of pieces. The clean price is expressed as a percentage of nominal, so MarketValue ≈ Nominal × (Price / 100), plus InterestClaimGross for the accrued coupon, sums to Position/TotalValue in the fund's base currency. There is no BondType enumeration; the sovereign-versus-corporate distinction lives on Issuer/Type (ECB sector codes) or in Classifications.
• For FX forwards, the mark-to-market lives in Position/TotalValue and may be positive or negative. The notional amounts live on the asset side in AssetDetails/FXForward/AmountBuy and AmountSell, paired with CurrencyBuy and CurrencySell. The position-side <FXForward> sub-block is almost empty — just HedgeRatio and FxRateForEvaluation. The mandatory Counterparty on the asset side uses CompanyType and must carry an LEI.
• For cash, one position per currency, AssetType=AC (or FT for fixed-term deposits, CM for call money), and the counterparty's LEI on AssetDetails/Account/Counterparty/Identifiers/LEI. There is no CashType enumeration — the account type is expressed through the two-character AssetType code.
• Portfolio breakdowns live in Portfolio/BreakDowns (not a separate root-level element) and are multi-dimensional by design. Each <BreakDown> names one or more <Dimension> strings and carries <Value> cells, each with a <DimValues> container (one <DimValue dim="..."> per dimension) and a mandatory <Percentage>. The structure is recursive: a cell can carry its own nested <BreakDowns>. Trust the producer's breakdowns and tolerate small rounding discrepancies; Chapter 10 formalises the tolerance.
• The Europa Growth Fund's portfolio consists of roughly 150 European equity positions, three cash accounts in three currencies, and two currency forwards implementing the CHF hedge from Chapter 5. The complete representation appears in Appendix D and anchors every fragment treated in the remaining chapters of Part II.

We know what the Europa Growth Fund holds on 31 March 2026. What we do not yet know is how it got there. Chapter 7 turns to the events that flow in and out of the fund every business day — subscriptions, redemptions, distributions, and corporate actions — and shows how each of them reshapes the portfolio from one valuation point to the next.

↑ Top

Transactions and OrdersFlows, distributions, and income events

---

7.1 Setting the Scene: How the Fund Got Where It Is

At the end of Chapter 6 we knew exactly what the Europa Growth Fund held on 31 March 2026 — the one hundred and fifty European equity positions, the three cash accounts, the two currency forwards of the CHF hedge overlay, the 464.5 million euros of total net assets. What we did not know was how it got there. Between the previous valuation point on 28 February 2026 and the present one, the fund lived through twenty-three trading days of small and not-so-small changes. Investors bought units and sold them back. A handful of investors moved from one share class to another. European companies paid dividends on the shares the fund holds. Each of these events is a transaction, and transactions are the part of fund data that make the dynamic half dynamic.

The chapter walks through the three real schema containers that FundsXML uses to carry these events. The first surprise for a newcomer — and the single most important fact of the chapter — is that transactions do not live in one central place. The real schema distributes them across three distinct containers at two different levels of the fund element:

• ShareClass/Flows/Flow (schema type FlowType) carries subscriptions and redemptions. It lives on the share-class side of SingleFund/ShareClasses, not inside FundDynamicData, because subscriptions and redemptions are by definition share-class-specific events.
• ShareClass/Distributions/Distribution (schema type DistributionType) carries dividend payout events in which a distributing share class pays its accumulated income out to its investors. Also share-class-specific.
• Portfolio/Earnings/Earning (schema type EarningType) carries the income events the fund receives from its portfolio holdings — dividends on shares the fund owns, coupons on bonds, interest on cash. These belong to the fund-level portfolio inside FundDynamicData/Portfolios/Portfolio, because they are properties of the fund's underlying asset pool, not of a specific share class.

Per-security portfolio trading — the portfolio manager buying and selling individual securities — has its own container, Portfolio/Transactions/Transaction (schema type TransactionType), and is not treated in this chapter; its explicit representation is a topic for Chapter 12 on system landscapes and Chapter 13 on implementation projects. The effect of portfolio trading is visible implicitly in the difference between consecutive portfolio snapshots, which we covered in Chapter 6.

The chapter structure reflects the schema. §7.2 walks through the three containers and their position in the fund element. §7.3 treats the common fields of FlowType — the schema type used for subscriptions, redemptions, and the two legs of a switch. §7.4 and §7.5 cover subscriptions and redemptions as the two values of FlowType/TransactionType (SUB and RED). §7.6 treats switches, which the schema represents as a pair of linked Flow entries rather than as a first-class transaction type. §7.7 treats distributions through DistributionType. §7.8 treats income events through EarningType. §7.9 honestly describes the order-execution concepts — cut-off times, forward pricing, swing pricing — that the core schema does not model and points at the producer-side mechanisms (CustomAttributes, EMT regulatory templates from Chapter 8) for carrying them where they matter. §7.10 assembles the complete transaction block for the Europa Growth Fund's March 2026 period; §7.11 and §7.12 close with pitfalls and takeaways.

One honest disclosure deserves to be made up front. The Europa Growth Fund's I-EUR-DIST share class pays its annual distribution in mid-May, not in March, and the 31 March 2026 delivery therefore contains no distribution-paid events. Rather than fabricate one for pedagogical convenience, the chapter treats the absence as a teachable moment: §7.7 shows a hypothetical May distribution to illustrate the structure, and §7.10's complete block honestly omits distributions. This respects both the integrity of the running example and the didactic need to show every event type.

By the end of this chapter, you should be able to:

• identify which of the three schema containers a given transaction belongs to and explain why;
• populate the fields of a FlowType entry (subscription or redemption), a DistributionType entry, and an EarningType entry correctly for a realistic scenario;
• distinguish the four date fields of FlowType — TradeDate, AccountingDate, SettlementDate, ValueDate — and choose the right one for each operational purpose;
• recognise the difference between distributions paid to investors (on ShareClass/Distributions) and income received from portfolio holdings (in Portfolio/Earnings), and never conflate the two;
• represent an intra-fund switch as the two linked <Flow> entries the schema actually demands;
• recognise that cut-off times, forward pricing, swing pricing, entry loads, and order-execution variants are operational concepts that the core FundsXML 4.2.8 schema does not model directly, and know where to carry them instead;
• read a complete transaction block for a European UCITS and cross-reference every event to its effect on NAV, shares outstanding, and the portfolio.

---

7.2 Where Transactions Live in the Schema

Before we look at any transaction in detail, the structural question: where, inside a FundsXML document, do transactions live? The answer is surprising to a newcomer and is the single most important thing to internalise before reading the per-type sections.

Transactions are not centralised. There is no single fund-level container for investor flows, distributions, and income events. Each event type lives in its own dedicated container, and each container is attached to a different parent element. The three containers are:

<Fund>
  <Identifiers>...</Identifiers>
  <Names>...</Names>
  <Currency>EUR</Currency>
  <SingleFundFlag>true</SingleFundFlag>
  <FundDynamicData>
    <Portfolios>
      <Portfolio>
        <NavDate>2026-03-31</NavDate>
        <!-- (1) Income received from portfolio holdings -->
        <Earnings from="2026-03-01" to="2026-03-31">
          <Earning>...</Earning>
          ...
        </Earnings>
      </Portfolio>
    </Portfolios>
  </FundDynamicData>
  <SingleFund>
    <ShareClasses>
      <ShareClass>
        <Identifiers>...</Identifiers>
        <Names>...</Names>
        <Currency>EUR</Currency>
        <!-- (2) Subscriptions and redemptions on this share class -->
        <Flows from="2026-03-01" to="2026-03-31">
          <Flow>...</Flow>
          ...
        </Flows>
        <!-- (3) Distributions paid by this share class to its investors -->
        <Distributions>
          <Distribution>...</Distribution>
        </Distributions>
      </ShareClass>
      <!-- more share classes, each with their own Flows and Distributions -->
    </ShareClasses>
  </SingleFund>
</Fund>

Three structural points matter for the rest of the chapter.

First, investor flows and distributions are share-class-specific. A subscription into the R-EUR-ACC class of the Europa Growth Fund goes into the <Flows> container of that specific share class, not into a fund-level flow list. A fund with three share classes has three <Flows> blocks, each carrying the flows of its own class. Likewise for <Distributions>: the distributing I-EUR-DIST class has its own <Distributions> block that the two accumulating classes do not share.

Second, portfolio income belongs to the fund-level portfolio, not to any share class. When the fund receives a dividend from an Allianz or BNP Paribas position in its portfolio, the event goes into the fund-level Portfolio/Earnings container. All three share classes benefit pro-rata from the income through their share of the fund's total net assets — the income is not re-attributed at the share-class level in the transaction data, only in the NAV roll-forward on valuation day.

Third, the Flows container carries two optional date attributes, @from and @to. They declare the reporting period covered by the aggregated flow data. For a monthly delivery with ContentDate 31 March 2026, a typical declaration is <Flows from="2026-03-01" to="2026-03-31">. The <Earnings> container carries the same pair of attributes for the same purpose. <Distributions> does not — a distribution is a single event with its own ex-date, not a period-aggregated collection.

Figure 7.1 — The transaction timeline

 Valuation point            Reporting period            Valuation point
 28 Feb 2026     ──────────────────────────────────→    31 Mar 2026
    │                                                        │
  TNAV:                                                     TNAV:
 461.2 M EUR            Flows (share-class)              464.6 M EUR
 Shares:                  7 SUB / 4 RED / 1 switch          Shares:
 4.01 M                     (11 Flow entries total          4.04 M
                             across three ShareClasses;
                             the switch = 2 linked Flows)

                         Earnings (portfolio)
                           3 dividend events

                         Distributions (share-class)
                           none (next in mid-May)

                              ↓
                         Schema locations:
                        Fund/FundDynamicData/Portfolios/
                             Portfolio/Earnings
                        Fund/SingleFund/ShareClasses/
                             ShareClass/Flows
                        Fund/SingleFund/ShareClasses/
                             ShareClass/Distributions

Between the two valuation points lie the events that explain the transition: TotalAssetValues and Portfolios (Chapters 5 and 6) give the states at either end, and the three transaction containers collectively give the transitions that connect them. A consumer that reconciles the fund's movement from one month to the next reads the opening state from the previous delivery, walks every <Flow> in every share class's <Flows>, every <Distribution> in every share class's <Distributions>, and every <Earning> in the fund-level <Earnings>, and checks that the resulting computed state matches the current delivery's TotalAssetValues and Portfolios. The reconciliation will almost always have small rounding artefacts, but any material discrepancy is a data-quality signal that deserves investigation.

One short remark to close the section: any of the three containers may legitimately be empty or absent — if no subscriptions or redemptions took place on a given class during the reporting period, its <Flows> block is either omitted entirely or present with no <Flow> children. Consumers should accept empty blocks without treating them as errors. A distribution-less month on the I-EUR-DIST class means no <Distributions> block at all — or, equivalently, a <Distributions> block with no children. Both are valid.

---

7.3 The Fields of FlowType

Symmetrical to §6.4 and §6.5 from Chapter 6: the fields that appear on every <Flow> element. Subscriptions, redemptions, and both legs of a switch all use the same schema type, FlowType, and differ only in the value of one mandatory discriminator child. This section walks through the common field set; §§7.4 through 7.6 look at the per-case idioms.

Table 7.1 — Children of <Flow> (schema type FlowType, XSD §25393), in sequence order

Child element	Schema type	Mandatory	Purpose
<ActionCode>	enum C/D/M	yes	Create, Delete, or Modify; C for all new transactions
<DataGroupedBy>	enum (repeatable)	no	Declares whether the data is aggregated by AccountingDate, TradeDate, Channel, InvestorType, etc. Nothing means single-transaction granularity.
<DataGroupedByFrequency>	FrequencyType	no	Period of the aggregation when <DataGroupedBy> names a date field
<TransactionID>	Text256Type	no	Unique identifier within the delivery (stable across deliveries by convention)
<TradeDate>	xs:date	no	Day the order was placed by the investor
<AccountingDate>	xs:date	yes	Day the transaction was booked into the producer's accounting system
<SettlementDate>	xs:date	no	Day cash and units actually change hands
<ValueDate>	xs:date	no	Day the transaction is effective on the customer account
<TransactionType>	enum SUB/RED	yes	The critical discriminator: subscription or redemption — there are only two values
<TransactionSubtype>	xs:string	no	Free-text annotation for sub-variants; used for switch, reinvested dividend, restructuring plan, etc.
<Netted>	xs:boolean	no	Whether the data is already netted against other flows
<Cancellation>	xs:boolean	no	Indicator for cancellation of a previously reported transaction
<OriginalTransactionID>	Text256Type	no	ID of a cancelled transaction, for reversal records
<Units>	xs:decimal	no	Number of units moved. Schema convention: always positive. Direction is expressed through <TransactionType>, not through the sign of <Units>.
<FXRate>	FXRatesType	no	FX rate used when the transaction currency differs from the class currency
<TotalValue>	FundAmountType	yes	Total value of the transaction, in the fund's base currency (and optionally also in the class currency)
<Channel>	Text256Type	no	Free text: Retail, Institutional, Wholesale, Web, Distribution partner, …
<InvestorID>	Text256Type	no	Opaque ID of the investor (hash or internal customer number, never a plain name)
<InvestorTypes>	InvestorTypesType	no	Structured investor-type classification (ECB, EMIR, AIFMD categories)
<InvestorCountry>	ISOCountryCodeType	no	Country of the investor

Four points about the table deserve to be made explicitly in running text rather than left implicit.

Four date fields, not three, and their semantic is subtly different from the textbook model. FlowType has <TradeDate>, <AccountingDate>, <SettlementDate>, and <ValueDate> — and only <AccountingDate> is mandatory. There is no element called EffectiveDate. The naming map to the operational concepts goes roughly as follows:

• <TradeDate> — the day the investor placed the order, as observed by the distributor. A subscription that reaches the distributor on Monday 16 March 2026 at 11:30 CET has TradeDate=2026-03-16.
• <AccountingDate> — the day the transaction was booked into the producer's accounting system. In the European forward-pricing model this is typically the same day as the trade date if the order arrived before the fund cut-off; orders that arrived after the cut-off get the next trading day's accounting date, and this is how the schema captures the "which NAV did the investor actually pay?" question. AccountingDate is the field that maps to the day whose NAV was applied, and it is the one mandatory date on every flow.
• <SettlementDate> — the day cash and units actually change hands at T+2 or T+3. A subscription booked on Monday 16 March 2026 settles on Wednesday 18 March (T+2, the Luxembourg standard) or Thursday 19 March (T+3).
• <ValueDate> — the day on which the transaction is effective on the investor's account for interest-accrual purposes. Often identical to AccountingDate in the European UCITS world, distinct only in specialised structures.

Consumers that compute NAV adjustments read AccountingDate; consumers that post cash movements to custodian accounts read SettlementDate; consumers that archive audit logs and timestamp orders read TradeDate. Only AccountingDate is mandatory, but producers should populate all four where they are known, because a consumer that finds one of them missing has to guess. The legacy textbook term effective date corresponds to AccountingDate in FundsXML vocabulary, and the safest reading discipline is to remember that the schema uses the word accounting, not effective, for the pricing-date field.

The <TransactionType> enumeration has only two values. SUB for subscription, RED for redemption. That is the entire schema-level taxonomy of flow events. There is no dedicated value for switch, distribution, income, or anything else — those event types either live in other containers (<Distributions>, <Earnings>) or are modelled as a pair of SUB/RED records tied together through <TransactionSubtype> and <TransactionID> conventions (§7.6 on switches). A producer that invents a FlowType enumeration with English labels is writing a different format, not FundsXML.

<Units> is always positive on FlowType — direction comes from <TransactionType>. The schema documentation states this explicitly: "Number of shares/units bought or sold (should be always positive)." A redemption of 15,000 units carries <Units>15000.0000</Units>, not -15000. The direction of the flow — is the fund receiving or paying out cash? — is carried exclusively by <TransactionType>. A consumer that infers direction from the sign of <Units> is reading a convention that the schema does not define and that many producers will not supply.

<TotalValue> is the one mandatory money amount, and it follows the fund-currency convention of Chapter 6. TotalValue is of type FundAmountType, so it can carry several <Amount ccy="…"> children at once — one in the fund's base currency (marked isFundCcy="true") and optionally one in the share class's native currency (marked isShareClassCcy="true"). For a subscription into the R-CHF-ACC-HEDGED class, a producer who wants to transport both figures writes two <Amount> children — one ccy="CHF" isShareClassCcy="true" for the investor's view and one ccy="EUR" isFundCcy="true" for the fund's reconciliation. There are no GrossAmount/NetAmount/EntryLoad/ExitLoad/NavUsed fields on FlowType. Entry loads and swing-pricing adjustments are operational concepts that the core schema does not model; producers that need to carry them use <CustomAttributes> on the share class or the regulatory-template cost fields of Chapter 8 (§7.9 returns to this).

<TransactionID> follows the same logic as UniqueID in Chapter 6 in the conventional sense: producers should make it unique within the delivery and stable across consecutive deliveries, so that consumers can reconcile. Unlike UniqueID on Asset, though, TransactionID is not declared as xs:ID in the schema — it is a plain Text256Type. This means the parser does not enforce uniqueness, and two <Flow> entries with the same TransactionID will schema-validate; the uniqueness discipline is purely a business convention. The recommended project-level convention is a deterministic string derived from the producer's order-management-system identifier, the event type, and the date — something like EGF-TX-20260316-0024. Chapter 13 will formalise this.

---

7.4 Subscriptions

The canonical <Flow> with <TransactionType>SUB</TransactionType>. Three subsections.

7.4.1 The Economic Model

A subscription is the operation in which an investor gives the fund cash and, in exchange, receives newly issued units of one of the fund's share classes. The economic flow is straightforward:

• The investor pays a cash amount into the share class's collection account.
• The share class computes how many units that cash amount buys at the relevant settlement NAV.
• New units are created; the class's total shares outstanding (which we saw in §5.12 as ShareClass/TotalAssetValues/TotalAssetValue/SharesOutstanding) increases by that count.
• The fund now has more cash to deploy — the portfolio manager will put the inflow to work in the next trading cycle by buying additional portfolio positions.

At the schema level, subscriptions are <Flow> entries inside the target share class's <Flows> container, with <TransactionType>SUB</TransactionType> as the discriminator. All of the common FlowType fields of §7.3 apply.

7.4.2 Pricing: When Is the NAV Struck

The critical conceptual question for subscriptions is which NAV does the investor pay? Three variants exist in the fund industry, but in the European UCITS world one of them dominates.

Forward pricing (the European standard): The investor places the order before a cut-off time (typically 13:00 CET for UCITS with daily valuation), and the NAV used to settle the order is the NAV that is computed at the end of the same trading day. At the moment the order is placed, the investor therefore does not know the price they are paying — they find out only after the markets close and the NAV has been computed. This is deliberate: forward pricing prevents "market timing", a practice in which an investor who already knows what the day's market movement will be exploits the stale NAV of the historic-pricing model to buy at yesterday's quote.

Historic pricing (rare, not UCITS-compatible): The investor buys at the last published NAV. This model is still used in a handful of AIFs and in some legacy structures, but it is effectively barred for UCITS by the regulation that followed the market-timing scandals of the early 2000s.

Market pricing (only for exchange-traded share classes): The investor buys the units on a stock exchange at the market quote, not at the fund's NAV. Creation and redemption by authorised participants happens in parallel through NAV-based processes, but ordinary retail investors in listed classes trade on the exchange at bid/ask prices that reflect, but are not identical to, the underlying NAV.

The Europa Growth Fund uses forward pricing on all three share classes. The cut-off is 13:00 CET on every Luxembourg trading day; orders received before the cut-off are settled at the NAV of the same day, and orders received after the cut-off are settled at the NAV of the next trading day. The consequence for the four date fields of §7.3 is concrete: <TradeDate> is the day the order was placed, <AccountingDate> equals <TradeDate> if the order was before the cut-off or equals <TradeDate> + 1 business day if it was after (the schema models the pricing-day decision through the accounting date, not through a dedicated field), and <SettlementDate> equals <AccountingDate> + 2 business days — T+2, the Luxembourg standard.

A note on what the schema does not model. FundsXML 4.2.8 does not carry the NAV that was actually applied to the subscription as an element on the <Flow>. The NAV is looked up indirectly by the consumer: the consumer reads the <AccountingDate> from the flow, then reads the NAV for that date from the share class's <Prices>/<Price> history (Chapter 5 §5.12.2). This decoupling is deliberate — the NAV history lives in one place, the transactions in another — and it keeps both halves small and composable. Similarly, entry loads, gross-versus-net breakdowns, and order-execution variants are not schema fields on <Flow>. §7.9 revisits why and explains what producers do when they need to carry them.

7.4.3 Subscription Example: A Retail Investor Subscribes to R-EUR-ACC

A complete XML example for a realistic subscription transaction. On Monday 16 March 2026 a retail investor subscribes 10,000 EUR to the R-EUR-ACC class of the Europa Growth Fund. The order is placed at 11:30 CET, comfortably before the 13:00 cut-off, so it is settled at the Monday evening NAV of 16 March 2026 — let us say 123.9504 EUR, representing a mid-March level between the February month-end and the 31 March figure of 124.5078 we saw in Chapter 5. The investor receives 10000 / 123.9504 = 80.6852 units. The <Flow> entry lives inside <ShareClass>/<Flows> for the R-EUR-ACC class (ISIN LU2100000011).

<!-- Inside Fund/SingleFund/ShareClasses/ShareClass[ISIN=LU2100000011]/Flows -->
<Flow>
  <ActionCode>C</ActionCode>
  <TransactionID>EGF-TX-20260316-0024</TransactionID>
  <TradeDate>2026-03-16</TradeDate>
  <AccountingDate>2026-03-16</AccountingDate>
  <SettlementDate>2026-03-18</SettlementDate>
  <ValueDate>2026-03-16</ValueDate>
  <TransactionType>SUB</TransactionType>
  <Units>80.6852</Units>
  <TotalValue>
    <Amount ccy="EUR" isFundCcy="true">10000.00</Amount>
  </TotalValue>
  <Channel>Retail</Channel>
</Flow>

Reading field by field: the <ActionCode>C</ActionCode> marks the entry as a new (create) record — the schema demands it, and every fresh transaction in a delivery carries C. The <TransactionID> is the producer's unique key. The four date fields reflect forward pricing: same-day trade and accounting (Monday pre-cut-off), T+2 settlement on Wednesday, and an explicit <ValueDate> for completeness. The mandatory <TransactionType>SUB</TransactionType> identifies the direction. <Units> is positive — the schema convention, regardless of direction — and carries the 80.6852 units the investor receives. The mandatory <TotalValue> carries the 10,000 EUR amount, flagged as being in the fund's base currency. The optional <Channel>Retail</Channel> annotates the customer segment.

Two observations are worth making. First, note what is not in the listing: no FlowType, no ShareClassISIN (the class is identified by the parent element), no Amount, no GrossAmount, no NetAmount, no EntryLoad, no NavUsed, no OrderExecutionType. All of those would be schema-invalid as direct children of <Flow>. Second, the consistency check 10000.00 / NavUsed = Units still applies in spirit, but the consumer has to look up the NAV from a different container: it reads the NAV for AccountingDate=2026-03-16 from ShareClass/Prices/Price and then verifies that Units × NavPrice ≈ TotalValue. The two halves of the check are in two different places, and that is by design.

---

7.5 Redemptions

The mirror operation of subscription, modelled as the second value of <TransactionType> — RED — in the same FlowType structure.

7.5.1 The Economic Model

A redemption is the operation in which an investor gives their units back to the fund and, in exchange, receives cash. The economic flow reverses the subscription:

• The investor submits a redemption order, typically for a specific number of units or for a specific cash amount.
• The share class computes how much cash those units are worth at the settlement NAV.
• The units are destroyed; the class's total shares outstanding decreases by that count.
• The fund pays out the amount and must source the cash for the payment, typically by selling portfolio positions in the next trading cycle.

At the schema level, a redemption is a <Flow> entry with <TransactionType>RED</TransactionType>. Every common FlowType field from §7.3 applies, with one important reminder: <Units> is still positive. The schema does not use the sign of <Units> to distinguish a redemption from a subscription — direction comes exclusively from <TransactionType>. A producer that writes a negative <Units> value on a redemption is fighting the schema's explicit convention.

7.5.2 Swing Pricing, Entry/Exit Loads, and the Concepts the Core Schema Does Not Model

A subtlety that distinguishes redemptions (and large subscriptions) from simple mirror arithmetic: when the fund has to redeem a large number of units at once, the payment produces transaction costs in the portfolio — the portfolio manager has to sell shares, and the sales themselves move the market slightly against the fund through the bid-ask spread and market impact. Without an adjustment, the remaining unit holders would bear the cost of the departing unit holders — a silent transfer of value from stayers to leavers that is known in the industry as "dilution".

Swing pricing is the standard mechanism to neutralise the dilution. When the net number of redemptions on a given trading day exceeds a threshold, the NAV used to settle all redemptions of that day is "swung" downward by a small amount — typically 10 to 50 basis points. The departing investors receive slightly less than the "normal" NAV, and the difference compensates for the transaction costs that will be incurred in the portfolio. Three swing-pricing variants exist in practice: full swing (applied to every transaction regardless of size), partial swing (applied only when net activity crosses a threshold), and dual pricing (separate bid and offer NAVs published permanently). The Europa Growth Fund operates partial swing with a 2% threshold.

The FundsXML 4.2.8 core schema does not model swing pricing, dilution levies, entry loads, or exit loads on FlowType. This is a deliberate architectural choice. The transaction container carries the what happened record — date, direction, unit count, total value — and leaves the pricing-adjustment details to other places in the document. Producers who need to carry these concepts have three options:

• <CustomAttributes> on the share class: Chapter 9 treats the <CustomAttributes> mechanism in detail, and for a share class with a swing-pricing regime a producer typically emits attributes such as SwingPricingType (with values Full/Partial/Dual), SwingPricingThreshold (a percentage), and SwingPricingFactor (basis points applied when the threshold is crossed). These attributes describe the regime, not individual swing events; the swing applied to a specific transaction is left implicit in the difference between Flow/TotalValue and Units × Price looked up from ShareClass/Prices.
• The EMT regulatory templates of Chapter 8 carry the full MiFID II cost disclosure, including entry and exit costs, ongoing charges, and performance fees. For regulatory consumers these are the authoritative source; for operational consumers the swing-pricing policy is a private contract between producer and distributor, carried through the custom attributes above.
• Project-level convention. Chapter 13 recommends specific <CustomAttributes> keys for swing pricing and entry-load carrying when producers and consumers agree on the convention.

There is therefore no XML example in this sub-section of a FlowType record that carries swing-pricing information directly — such an example would be schema-invalid. The operational concepts remain important, and Chapter 13 returns to them in the context of implementation projects; but readers who expect to find <NavUsed>, <SwingAdjustment>, <NetNavUsed>, <EntryLoad>, or <ExitLoad> on a FundsXML flow will not find them, because they are not there.

7.5.3 Redemption Gates and Deferred Redemptions

An extreme case: when a fund receives more redemption orders than it can serve in a single trading cycle (typically because the underlying positions are illiquid and cannot be sold fast enough), the fund can hold back redemptions. Two mechanisms exist. Redemption gates execute only a fraction of the orders on the current day and defer the rest to the next day (or over several days). Suspensions freeze redemptions entirely until the liquidity situation improves. Both mechanisms are provided for in UCITS prospectuses but are practically activated only in crises — the 2008 financial crisis, the March 2020 COVID shock, the 2022 UK gilt-market turbulence that hit LDI funds.

FundsXML has no dedicated fields for gates or suspensions either. Partial executions are modelled as separate <Flow> records — a redemption for the executed units today, a second redemption for the remaining units tomorrow, both tied together by a common <TransactionID> prefix or by referring to each other through <OriginalTransactionID> in the same spirit as the cancellation mechanism of §7.3. The Europa Growth Fund has never activated a gate, and the example block in §7.10 will not show one.

7.5.4 Redemption Example

An institutional redemption from the I-EUR-DIST class: on 20 March 2026 a pension fund submits an order to redeem 15,000 units. At the Friday evening NAV of that day — 107.8421 EUR, a mid-March value — the redemption is worth approximately 1.62 million EUR. No swing (the amount is well below the 2% threshold). Settlement T+2 puts the cash payment on 24 March. The <Flow> entry lives inside <ShareClass>/<Flows> for the I-EUR-DIST class (ISIN LU2100000037).

<!-- Inside Fund/SingleFund/ShareClasses/ShareClass[ISIN=LU2100000037]/Flows -->
<Flow>
  <ActionCode>C</ActionCode>
  <TransactionID>EGF-TX-20260320-0011</TransactionID>
  <TradeDate>2026-03-20</TradeDate>
  <AccountingDate>2026-03-20</AccountingDate>
  <SettlementDate>2026-03-24</SettlementDate>
  <ValueDate>2026-03-20</ValueDate>
  <TransactionType>RED</TransactionType>
  <Units>15000.0000</Units>
  <TotalValue>
    <Amount ccy="EUR" isFundCcy="true">1617631.50</Amount>
  </TotalValue>
  <Channel>Institutional</Channel>
</Flow>

Reading field by field, focusing on the differences from §7.4.3: the single mandatory change is <TransactionType>RED</TransactionType> — that one field is the entire difference between a subscription and a redemption at the schema level. <Units> is positive (15000.0000), following the schema's explicit convention, even though the economic direction is outflow. The <Channel>Institutional</Channel> annotates the customer segment differently from the retail subscription of §7.4.3. Everything else — the four date fields, the <ActionCode>, the <TotalValue> — follows the same pattern as the subscription example, which is the whole point: subscriptions and redemptions are the same schema shape distinguished by a single enum value.

---

7.6 Switches — Two Linked Flow Entries

The third transaction type conceptually, but not a third schema type. This is the single biggest surprise of the chapter for anyone coming from a textbook fund-data background.

7.6.1 The Schema Has No "Switch" Transaction Type

A switch is, economically, the combination of two events: a redemption from one share class (the source) and a simultaneous subscription to another share class (the target). The distinguishing feature is that both legs are settled at the same accounting date, at the same trade timestamp, and the two are economically linked — the proceeds of the redemption flow directly into the subscription, without the investor receiving cash in between.

The FundsXML 4.2.8 schema has no dedicated Switch transaction type. The <TransactionType> enumeration on FlowType has only two values, SUB and RED, and there is no third value for switches. Consequently, a switch is modelled as two separate <Flow> entries:

• one <Flow> with <TransactionType>RED</TransactionType> inside the source class's <Flows> container;
• one <Flow> with <TransactionType>SUB</TransactionType> inside the target class's <Flows> container.

The two entries are linked by convention, not by a first-class schema relationship. The two most common linking conventions are:

• Shared <TransactionID> prefix: both legs carry a <TransactionID> whose prefix identifies the switch (e.g. EGF-SW-20260312-0007-SRC and EGF-SW-20260312-0007-TGT) so that a consumer can pair them by string match.
• <TransactionSubtype> annotation: both legs carry a <TransactionSubtype> value starting with switch (the schema element is a free-text xs:string, so any convention is allowed) together with a reference to the paired leg's <TransactionID>. The schema documentation lists restructuring plan and similar free-text conventions as typical values.

Most producers use both conventions simultaneously. A consumer that wants to reconstruct switches walks every <Flow> across every share class, groups pairs by the prefix or by the subtype reference, and reports the combined event to its downstream pipeline as a single conceptual switch. A consumer that does not know to look for the pairing reads the two legs as an independent redemption and an independent subscription — and that is an acceptable reading for most use cases, because the two legs net to zero at the fund level. The switch interpretation matters only for consumers that track investor-level holdings across classes, and those consumers know to look for the pairing.

This two-record model is a genuine surprise for anyone coming from a format that models switches as first-class transactions. The schema's choice is deliberate: it avoids introducing a three-valued <TransactionType> that would need its own rules for quantity and cash-flow direction, and it lets every <Flow> continue to be a self-contained record that can be processed independently. The cost is that switch reconciliation is a consumer-side concern, and the quality of the pairing depends on the producer's naming discipline.

7.6.2 Intra-Fund Versus Inter-Fund Switches

Two variants exist, and they differ in operational meaning as well as in schema location.

An intra-fund switch moves an investor's holding from one share class to another of the same fund. Example: a retail investor in the R-EUR-ACC class of the Europa Growth Fund crosses the institutional threshold through portfolio growth and switches to the I-EUR-DIST class to benefit from the lower institutional fee schedule. The switch is economically a non-event for the fund itself — the underlying portfolio does not change; only the share-class attribution of one investor's stake shifts. SharesOutstanding of R-EUR-ACC decreases, SharesOutstanding of I-EUR-DIST increases, and the fund's total net assets remain unchanged.

In the schema, both legs of an intra-fund switch live in the same fund's <SingleFund>/<ShareClasses> block — one in the source class's <Flows>, one in the target class's <Flows>. Both are in the same delivery and both refer to classes visible in the same document.

These switches are cost-free for the fund because they do not trigger any portfolio activity, and most asset managers therefore charge no switch fee on intra-fund moves. They are nevertheless transactions that must be reported, because they change the distribution of shares outstanding across the classes, and consumers that track per-class metrics need to see both legs.

An inter-fund switch moves an investor's holding between share classes of different funds that belong to the same umbrella. Example: an investor in the Europa Growth Fund wants to move to another sub-fund of the same SICAV — a hypothetical Europa Asset Management Investments — Emerging Markets Sub-Fund, for instance. The umbrella structure introduced in Chapter 5.14 permits this kind of switch, and many distributors offer it as a convenience feature that avoids the tax friction of a full market-exit-and-re-entry.

Inter-fund switches are more complex because they touch the portfolios of both funds: the source fund must raise cash (selling positions), the target fund must deploy cash (buying positions). In the schema, the two <Flow> legs live inside different <Fund> elements — one inside the source fund's <SingleFund>/<ShareClasses>/<ShareClass>/<Flows>, one inside the target fund's. Both affected funds report their own leg in their own delivery (or in different segments of the same multi-fund delivery), and a consumer that reconstructs the full switch needs to see both funds' data.

The Europa Growth Fund, as we established in Chapter 5.14, is shown as a standalone fund in the running example rather than as a sub-fund of a larger umbrella. Inter-fund switches are therefore not represented in the chapter's complete example; Chapter 13 will return to them when it treats umbrella implementation projects.

7.6.3 Switch Example

A small intra-fund switch: on 12 March 2026 an investor moves a 50,000 EUR stake from the R-EUR-ACC class to the I-EUR-DIST class. The amount is in reality below the institutional minimum of 1,000,000 EUR and the switch would be rejected by a well-configured order-management system, but for the purpose of illustrating the structure we let it through. The source NAV is 123.7021 EUR (a 12 March value for R-EUR-ACC), the target NAV is 107.7413 EUR (the same day for I-EUR-DIST). The investor gives up 50000 / 123.7021 = 404.2156 units of R-EUR-ACC and receives 50000 / 107.7413 = 464.0882 units of I-EUR-DIST.

Leg 1 — source redemption, inside the R-EUR-ACC class's <Flows>:

<!-- Inside Fund/SingleFund/ShareClasses/ShareClass[ISIN=LU2100000011]/Flows -->
<Flow>
  <ActionCode>C</ActionCode>
  <TransactionID>EGF-SW-20260312-0007-SRC</TransactionID>
  <TradeDate>2026-03-12</TradeDate>
  <AccountingDate>2026-03-12</AccountingDate>
  <SettlementDate>2026-03-16</SettlementDate>
  <ValueDate>2026-03-12</ValueDate>
  <TransactionType>RED</TransactionType>
  <TransactionSubtype>switch — source leg; paired with EGF-SW-20260312-0007-TGT on LU2100000037</TransactionSubtype>
  <Units>404.2156</Units>
  <TotalValue>
    <Amount ccy="EUR" isFundCcy="true">50000.00</Amount>
  </TotalValue>
  <Channel>Intra-fund switch</Channel>
</Flow>

Leg 2 — target subscription, inside the I-EUR-DIST class's <Flows>:

<!-- Inside Fund/SingleFund/ShareClasses/ShareClass[ISIN=LU2100000037]/Flows -->
<Flow>
  <ActionCode>C</ActionCode>
  <TransactionID>EGF-SW-20260312-0007-TGT</TransactionID>
  <TradeDate>2026-03-12</TradeDate>
  <AccountingDate>2026-03-12</AccountingDate>
  <SettlementDate>2026-03-16</SettlementDate>
  <ValueDate>2026-03-12</ValueDate>
  <TransactionType>SUB</TransactionType>
  <TransactionSubtype>switch — target leg; paired with EGF-SW-20260312-0007-SRC on LU2100000011</TransactionSubtype>
  <Units>464.0882</Units>
  <TotalValue>
    <Amount ccy="EUR" isFundCcy="true">50000.00</Amount>
  </TotalValue>
  <Channel>Intra-fund switch</Channel>
</Flow>

Four points are worth noting about this pair.

First, the two legs live in different parent elements — one inside the R-EUR-ACC <ShareClass>, one inside the I-EUR-DIST <ShareClass>. They are not siblings. A consumer that scans <Flow> entries in document order and looks for pairs has to walk across share classes.

Second, the two <Units> values are not equal, because the two classes have different NAVs — the investor gives up 404.2156 units of R-EUR-ACC and receives 464.0882 units of I-EUR-DIST, both corresponding to a 50,000 EUR value. The unit count changes, but the economic value does not. Both <Units> values are positive, following the schema convention, and the direction is carried through <TransactionType> (RED on the source, SUB on the target).

Third, both legs carry identical <TotalValue> — the 50,000 EUR common amount that ties the two legs together economically. A consumer that wants to compute the net flow for the fund sees the source leg as an outflow (because <TransactionType>RED</TransactionType>) and the target leg as an inflow (because <TransactionType>SUB</TransactionType>); the two cancel to zero at the fund level. A consumer that does not recognise the switch pairing still gets the right answer — because the +50,000 and −50,000 net to zero — but displays the move as two separate transactions on the investor's statement instead of as one.

Fourth, the <TransactionSubtype> free-text annotation starts with the word switch and names the paired leg's <TransactionID>. This is a project-level convention rather than a schema rule, but it is the standard way to make the pairing discoverable to a consumer that wants to reconstruct switches. Chapter 13 formalises the convention for projects that care about investor-level reconciliation.

---

7.7 Distributions Paid to Investors

The fourth event type — and one that, for the Europa Growth Fund on 31 March 2026, does not apply. The distribution for the I-EUR-DIST class is an annual event in mid-May, and no distribution event belongs to the March reporting period. This section treats the mechanics and the fields nonetheless, because other funds use distributions constantly and because the Europa Growth Fund will emit a distribution event in its May 2026 delivery.

7.7.1 The Schema Container

Distributions live in ShareClass/Distributions/Distribution, schema type DistributionType (XSD §7197). The container is attached to the individual distributing share class — in the Europa Growth Fund's case, to the I-EUR-DIST class only — and lists the distribution events that have been declared for that class. A delivery that carries no distribution event for the reporting period either omits the <Distributions> container entirely or emits it empty; both forms are schema-valid.

The container is not period-scoped the way <Flows> and <Earnings> are; there are no @from/@to attributes on <Distributions>. A delivery carries the distribution events whose announcement or ex-date falls inside the reporting period, but the scoping is purely by content, not by a container attribute.

7.7.2 The Mechanics of a Distribution and the Four Dates

A distribution is the operation in which a distributing share class pays a portion of its accumulated income out to its investors. The mechanics run through four distinct dates, all of which the schema models:

• Announcement date (<AnnouncementDate>, optional) — the day the fund's board resolves the distribution and publishes its amount. The schema calls this AnnouncementDate rather than the legacy industry term declaration date, and a producer writing <DeclarationDate> will fail validation.
• Record date (<RecordDate>, optional) — the day the list of distribution recipients is formally recorded. Typically one or two trading days after the ex-date.
• Ex-date (<ExDate>, mandatory) — the day the class's units trade "without entitlement to the distribution". Any investor holding units at the ex-date receives the distribution; anyone who buys units after the ex-date does not. The class's NAV drops on the ex-date by the per-unit distribution amount, because the class has booked the distribution as a liability to its investors.
• Payment date (<PaymentDate>, mandatory) — the day the cash actually flows to the investors' accounts. Several weeks after the ex-date in most jurisdictions.

The order in the schema sequence is unusual: AnnouncementDate?, RecordDate?, ExDate, PaymentDate. Note that RecordDate comes before ExDate in XML element order, even though operationally it happens after. A producer must emit the elements in schema order regardless of the operational sequence of events.

7.7.3 The Amount Structure

The distribution amount is carried through two mandatory amount blocks that mirror each other: <GrossDividendAmount> and <NetDividendAmount>. Each is a small structured element with two children:

• <Total> (optional, PositiveAmountType) — the total payout flowing out of the fund.
• <PerShare> (mandatory, PositiveAmountType) — the payout per unit of the share class.

Both amount blocks use PositiveAmountType, which is FundAmountType restricted to non-negative values. The element names are DividendAmount even for distributions that are not formally dividends — the schema uses dividend as a generic term for "payout to investors".

There is no <DistributionSubType> element. The schema does not distinguish Interim/Final/CapitalGains/ReturnOfCapital at the DistributionType level. A producer that needs to carry the distinction does so either through the free-text <Comments> field at the bottom of DistributionType or through <CustomAttributes> on the share class. In practice the subtype is a tax-reporting concern rather than a schema concern, and the distinction is carried in the regulatory reporting of Chapter 8.

There is no <SharesAtRecord> element. The shares outstanding at the record date are not a field of DistributionType. A consumer that needs the figure reads it from the share class's <TotalAssetValues>/<SharesOutstanding> as of the record date, or computes Total / PerShare from the two amount children.

7.7.4 Other Mandatory Fields

On top of the four dates and the two amount blocks, DistributionType carries three more mandatory children that a producer must populate on every entry:

• <ActionCode> — enum C/D/M, as on every other dynamic record in the schema.
• <DividendStatus> — enum ESTIMATED or OFFICIAL. ESTIMATED is used for distributions whose amount has been announced but not yet formally resolved; OFFICIAL for distributions whose amount is final. A delivery between announcement and formal resolution might carry the same distribution first with ESTIMATED and then, in a later delivery, with OFFICIAL.
• <PaymentCurrency> — ISO 4217 code. Usually matches the share class's currency but can differ for classes that pay out in a different currency than they are denominated in (rare).

Seven mandatory children in total, in this order: ActionCode, DividendStatus, ExDate, PaymentDate, PaymentCurrency, GrossDividendAmount, NetDividendAmount.

7.7.5 The Europa Growth Fund's Situation and a Hypothetical Example

Honest disclosure to the reader: the 31 March 2026 delivery of the Europa Growth Fund contains no distribution events. The reason is straightforward: the I-EUR-DIST class pays its annual distribution in mid-May, with an announcement date in early May, an ex-date around 15 May, a record date around 17 May, and a payment date around 27 May. The March delivery sees none of this. The complete example in §7.10 will respect this fact and will not contain a distribution entry, rather than fabricating one for pedagogical convenience.

For the purpose of illustrating the structure, however, this subsection shows the hypothetical May distribution as it would appear in the May 2026 delivery of the fund. The assumed values are: announcement date 5 May, record date 17 May, ex-date 15 May, payment date 27 May, gross per share 3.80 EUR, net per share 3.50 EUR (after 7.9% withholding at the fund level), shares outstanding 2,350,000 at record.

<!-- Inside Fund/SingleFund/ShareClasses/ShareClass[ISIN=LU2100000037]/Distributions -->
<Distribution>
  <ActionCode>C</ActionCode>
  <DividendStatus>OFFICIAL</DividendStatus>
  <AnnouncementDate>2026-05-05</AnnouncementDate>
  <RecordDate>2026-05-17</RecordDate>
  <ExDate>2026-05-15</ExDate>
  <PaymentDate>2026-05-27</PaymentDate>
  <PaymentCurrency>EUR</PaymentCurrency>
  <GrossDividendAmount>
    <Total>
      <Amount ccy="EUR" isFundCcy="true">8930000.00</Amount>
    </Total>
    <PerShare>
      <Amount ccy="EUR" isShareClassCcy="true">3.80</Amount>
    </PerShare>
  </GrossDividendAmount>
  <NetDividendAmount>
    <Total>
      <Amount ccy="EUR" isFundCcy="true">8225000.00</Amount>
    </Total>
    <PerShare>
      <Amount ccy="EUR" isShareClassCcy="true">3.50</Amount>
    </PerShare>
  </NetDividendAmount>
  <DistributionFlag>true</DistributionFlag>
</Distribution>

Reading field by field: <ActionCode>C</ActionCode> marks the entry as a create record. <DividendStatus>OFFICIAL</DividendStatus> signals that the distribution amount has been formally resolved by the board. The four dates — AnnouncementDate, RecordDate, ExDate, PaymentDate — are listed in schema order (not in operational order). <PaymentCurrency>EUR</PaymentCurrency> matches the I-EUR-DIST class's currency. The two mandatory amount blocks, <GrossDividendAmount> and <NetDividendAmount>, each carry the total payout and the per-share figure; the net is smaller because of a 7.9% fund-level withholding. <DistributionFlag>true</DistributionFlag> is an optional boolean that explicitly confirms the distribution will actually be distributed (as opposed to reinvested as an accrual).

One important corollary that the schema models indirectly: the NAV of the I-EUR-DIST class drops on the ex-date of 15 May 2026 by approximately 3.80 EUR per unit. If the NAV on 14 May was, say, 111.20 EUR, the NAV on 15 May would be approximately 107.40 EUR (111.20 minus 3.80), ignoring any other market movement between the two valuation points. The NAV time series carried in ShareClass/Prices/Price (Chapter 5 §5.12.2) shows this as a discrete downward jump — exactly the sawtooth pattern that distinguishes distributing classes from their accumulating counterparts, as §5.10.1 explained. The drop is not a loss; it is the mechanical consequence of moving accumulated income from "inside the NAV" to "inside the investors' cash accounts".

---

7.8 Income Received from the Portfolio

The fifth event type — and the counterpart to §7.7: money that flows into the fund from its portfolio holdings, rather than out from the fund to investors. The schema container is different, the schema type is different, and the wrapper element lives one level up — at the fund-level portfolio rather than inside a share class.

7.8.1 The Schema Container and the Fund-Portfolio-Not-Share-Class Rule

Income events live in Portfolio/Earnings/Earning, schema type EarningType (XSD §7556). The <Earnings> container is a child of Portfolio and appears inside Fund/FundDynamicData/Portfolios/Portfolio — the same fund-level portfolio where the positions and transactions of Chapter 6 live. The container carries two optional attributes, @from and @to, that bracket the reporting period.

The critical difference from §7.7 is the level of attachment. Income events are attached to the fund's portfolio, not to any share class. When the fund receives a dividend from a portfolio holding, the event is a property of the fund's asset pool, not of a specific class. All three share classes benefit pro-rata from the income through their share of the fund's total net assets; that pro-rata split is implicit in the valuation-day NAV calculation and is not re-recorded in the transaction data.

The distinction from §7.7 is important enough to repeat: distributions in ShareClass/Distributions flow out of a share class to its investors; earnings in Portfolio/Earnings flow into the fund from its portfolio positions. The two are economic opposites, live in different containers, and use different schema types. A producer that mislabels an income event as a distribution causes a pair of reconciliation failures: the fund appears to lose cash that it should have gained, and the distribution appears to come from an imaginary source.

7.8.2 The EarningKind Enumeration

Every <Earning> carries a mandatory <EarningKind> element drawn from a fixed six-value enumeration:

• Coupon — a coupon payment on a bond held by the fund. The bond pays its periodic coupon (annually, semi-annually, or quarterly depending on the coupon frequency from §6.7.1) and the fund receives the corresponding cash. Coupons are contractually fixed in the bond prospectus, not decided each year by the issuer. The <InterestClaimGross> from §6.7.2 resets to zero at the coupon payment date, and the accumulated amount flows as cash into the fund.
• Dividend — a dividend on an equity held by the fund. The most common case in an equity fund like the Europa Growth Fund. The workflow follows the usual ex-date / record / payment pattern, but from the fund's perspective the ex-date is the day the claim arises (booked as a receivable against the issuer) and the payment date is the day the cash arrives. The gap between the two is typically several weeks.
• Fund distribution — when the fund holds a position in another fund (§6.8), and that fund distributes to its holders, the received distribution is an income event from our fund's perspective.
• Interest deposit/giro — interest on cash balances. The custodian bank pays the fund periodically at the agreed rate on its balances (or charges negative interest, depending on the market environment). Most commonly settled monthly.
• Interest swap — interest payments arising from a swap contract's leg.
• Other — the catch-all for events that do not fit the first five.

Note the exact spelling of each value — the schema is case-sensitive and space-sensitive. Interest deposit/giro with its lowercase "deposit" and embedded slash is the real spelling; a producer that writes InterestDeposit or Interest Deposit will fail validation.

7.8.3 The Common EarningType Fields and the Typed Sub-Block

EarningType has two layers. The common layer carries fields that apply to every kind of earning; the typed layer is an optional choice of three sub-elements — <Coupon>, <Dividend>, <FundDistribution> — that carries kind-specific breakdowns.

The mandatory common fields, in schema order, are:

• <EarningID> — a Text256Type unique identifier for the earning record. Analogous to <TransactionID> on FlowType and the same conventions apply (unique within delivery, stable across deliveries, not declared as xs:ID).
• <EarningKind> — the six-value enumeration from §7.8.2.
• <EntryDate> — the date the earning was booked into the portfolio. Analogous to <AccountingDate> on FlowType.
• <EntryCurrency> — the currency in which the earning is booked in the fund's ledger. Usually the fund's base currency; can differ for funds that keep their books in multiple currencies.
• <EntryValue> — a FundAmountType carrying the consolidated value of the earning in the fund's base currency (and optionally also in the income currency).

Optional common fields include <CancellationFlag> and <OriginalEarningID> for reversal records, <AssetUniqueID> (an xs:IDREF pointing at the asset in AssetMasterData — the same IDREF mechanism as positions use), <Identifiers> for an inline copy of the instrument codes, <ClosingDate> (the trade date — earlier than EntryDate when the booking lags the trade), <ValutaDate> (the effective date for interest-accrual purposes), <IncomeCurrency> (the currency the issuer paid in, when different from EntryCurrency), <Interests> (interest value where applicable), <NominalValueOrUnits> (the shares or nominal amount the earning was based on), <ReferenceNumber>, <AccountNumber>, <PostingText>, and <FinallySettled>.

The typed sub-block at the end of EarningType is an optional choice of three inline complex types:

• <Dividend> — carries <DividendPerUnitValue>, <DividendGrossValue>, <DividendNetValue>, <WithholdingTaxValue>, <ExDay>, <PayDay>, <WithholdingTaxQuota>. All optional, but populated on every real dividend event.
• <Coupon> — carries <UnitInterestsGrossValue>, <UnitInterestsNetValue>, <CapitalYieldsTaxValue>, <EUWithholdingTaxValue>.
• <FundDistribution> — carries <PayoutPerUnitValue>, <PayoutGrossValue>, <CapitalYieldsTaxUnitValue>, <CapitalYieldsTaxOverallValue>, <EUWithholdingTaxUnitValue>, <EUWithholdingTaxOverallValue>, <PayoutIdenticEarningsValue>, <ExDay>.

Exactly one of the three may be present (the choice is optional), and its name matches the <EarningKind> value on the common layer: an EarningKind=Dividend entry carries a <Dividend> sub-block, a Coupon entry carries a <Coupon> sub-block, and so on. The three cash enumerations (Interest deposit/giro, Interest swap, Other) do not have their own sub-block and populate only the common layer.

7.8.4 Withholding Tax

A tax detail that sets income events apart from the other event types: foreign dividends are typically taxed at source. A Luxembourg-domiciled fund receiving dividends from a German share sees approximately 26.375% German withholding tax deducted before the net amount arrives in Luxembourg. Depending on the double-taxation treaty between the two countries and on the fund's legal structure, a portion of the withheld amount may later be reclaimable, but at the moment of the payment the fund sees only the net.

FundsXML models withholding tax inside the typed sub-block. For a dividend event, the relevant fields are <DividendGrossValue>, <DividendNetValue>, <WithholdingTaxValue>, and <WithholdingTaxQuota> — all inside <Earning>/<Dividend>. Consumers that compute fund performance use <DividendGrossValue>; consumers that reconcile cash balances use <DividendNetValue>. Both are authoritative for their respective use cases, and both should be populated on every dividend from a taxable source. <WithholdingTaxValue> is the absolute amount kept at source, and <WithholdingTaxQuota> is the rate as a percentage (in the schema's standard human-readable per-cent convention: 26.375 means 26.375%, not 0.26375).

The common-layer <EntryValue> typically carries the net amount — the amount that actually arrived in the fund's ledger. A producer that wants to reconcile cash balances reads EntryValue; a producer that wants the gross figure reads Dividend/DividendGrossValue. The two are both populated, intentionally, and the consumer picks whichever is appropriate.

7.8.5 Income Example: A BNP Paribas Interim Dividend

An example of an income event drawn from the actual portfolio of the Europa Growth Fund. BNP Paribas (ISIN FR0000131104, 110,000 shares in the portfolio per Chapter 6) pays an interim dividend in Q1, with an ex-date of 20 March 2026 and a payment date of 24 March 2026. The interim amount is 1.50 EUR per share. The gross cash flow to the fund is 110,000 × 1.50 = 165,000.00 EUR. France applies a 25% withholding tax on dividends paid to foreign recipients under the France-Luxembourg tax treaty, so the fund receives 165,000.00 × 0.75 = 123,750.00 EUR net.

<!-- Inside Fund/FundDynamicData/Portfolios/Portfolio/Earnings -->
<Earning>
  <EarningID>EGF-EARN-20260320-0012</EarningID>
  <AssetUniqueID>FR0000131104</AssetUniqueID>
  <EarningKind>Dividend</EarningKind>
  <ClosingDate>2026-03-20</ClosingDate>
  <EntryDate>2026-03-24</EntryDate>
  <ValutaDate>2026-03-24</ValutaDate>
  <EntryCurrency>EUR</EntryCurrency>
  <IncomeCurrency>EUR</IncomeCurrency>
  <EntryValue>
    <Amount ccy="EUR" isFundCcy="true">123750.00</Amount>
  </EntryValue>
  <NominalValueOrUnits>110000</NominalValueOrUnits>
  <PostingText>BNP Paribas Q1 interim dividend, net of 25% French withholding tax</PostingText>
  <Dividend>
    <DividendPerUnitValue>
      <Amount ccy="EUR">1.50</Amount>
    </DividendPerUnitValue>
    <DividendGrossValue>
      <Amount ccy="EUR" isFundCcy="true">165000.00</Amount>
    </DividendGrossValue>
    <DividendNetValue>
      <Amount ccy="EUR" isFundCcy="true">123750.00</Amount>
    </DividendNetValue>
    <WithholdingTaxValue>
      <Amount ccy="EUR">41250.00</Amount>
    </WithholdingTaxValue>
    <ExDay>2026-03-20</ExDay>
    <PayDay>2026-03-24</PayDay>
    <WithholdingTaxQuota>25.00</WithholdingTaxQuota>
  </Dividend>
</Earning>

Reading field by field: the <EarningID> is the producer's unique key for the earning. The <AssetUniqueID> is the back-pointer to the asset entry in AssetMasterData (Chapter 6) through an xs:IDREF — the consumer sees FR0000131104 and knows immediately that the event concerns the BNP Paribas position. <EarningKind>Dividend</EarningKind> selects the <Dividend> sub-block at the bottom.

The three date fields on the common layer — <ClosingDate>, <EntryDate>, <ValutaDate> — tell different parts of the story. ClosingDate=2026-03-20 is the dividend's ex-date, the day the claim arose. EntryDate=2026-03-24 is the day the cash was booked into the fund's ledger (four days later, once the payment actually arrived). ValutaDate=2026-03-24 is the day the amount was effective on the cash account for interest-accrual purposes. For a simple dividend received into a current account, EntryDate and ValutaDate are usually the same day.

<EntryCurrency>EUR</EntryCurrency> names the ledger currency; <IncomeCurrency>EUR</IncomeCurrency> names the currency the issuer paid in. For a French dividend paid to a euro-base fund, both are EUR; for a British dividend paid to the same fund, IncomeCurrency would be GBP and EntryCurrency would still be EUR (reflecting the custodian's FX conversion). <EntryValue> carries the consolidated net amount in the fund's base currency; <NominalValueOrUnits>110000</NominalValueOrUnits> records the 110,000 shares the fund held at the ex-date — and the schema annotation deliberately uses the nominal or units naming to cover both equities (units) and bonds (nominal).

The <Dividend> sub-block at the bottom carries the kind-specific breakdown. DividendPerUnitValue=1.50 EUR, DividendGrossValue=165000.00 EUR, DividendNetValue=123750.00 EUR, WithholdingTaxValue=41250.00 EUR, ExDay=2026-03-20, PayDay=2026-03-24, WithholdingTaxQuota=25.00. Note the duplication: ExDay in the sub-block mirrors ClosingDate on the common layer, and PayDay mirrors EntryDate. The duplication is deliberate — the sub-block names come from the dividend-specific vocabulary, the common-layer names come from the generic-earning vocabulary, and both are populated so that consumers reading either layer get a consistent picture.

One operational note: the <NominalValueOrUnits> field on the income event is the number of shares that were held at the record date of the dividend, not the number held on the delivery's valuation date. If the fund had bought additional BNP Paribas shares between the dividend's record date and the valuation date, the position from Chapter 6 would show the higher current count, while the earning event's NominalValueOrUnits would record the lower count that actually earned the dividend. The two figures therefore legitimately differ, and consumers that reconcile dividend receipts against positions need to use the record-date shares rather than the current shares.

---

7.9 Order Execution, Cut-offs, and the Operational Concepts the Core Schema Does Not Model

The concluding structural section of the chapter, and conceptually distinct from the preceding sections: it treats a set of operational concepts — forward pricing, cut-off times, order-execution variants, in-kind creation, market-traded execution — that every UCITS operates with, but that the FundsXML 4.2.8 core schema does not model on <Flow>. Producers that need to carry these concepts use mechanisms outside the core transaction containers, and this section walks through what exists, what doesn't, and where the operational data actually lives.

7.9.1 What the Schema Does and Does Not Carry on <Flow>

We said this in §7.4.2 and §7.5.2, but it deserves one more explicit statement: the core FlowType has no element called OrderExecutionType, no element called NavUsed, no element called NetNavUsed, and no element called SwingAdjustment. There are no enumeration values AtNAV, ForwardDated, HistoricPriced, Market, Negotiated, or InKind anywhere in the schema. A producer that writes any of these elements or values will fail schema validation.

The operational concepts these labels describe are real — forward pricing, cut-off times, dilution levies, in-kind creation, market-priced ETF trades, negotiated institutional blocks — and they matter every day in European fund distribution. The schema's position is that the <Flow> record captures the outcome of these mechanisms (the direction, the unit count, the total value, the dates) and not the process that produced them. If a consumer needs to know whether a specific trade was executed at NAV or on an exchange, that information lives somewhere else in the delivery or in a separate file entirely.

7.9.2 Cut-Off Times and the Forward-Pricing Model

The forward-pricing mechanism depends on a critical concept: the cut-off time, the moment in the trading day by which an order must be received in order to be settled at the NAV of that day. Orders received after the cut-off are rolled over to the next trading day.

The cut-off is understood at two levels in practice:

• The fund cut-off — specified in the prospectus, typically 12:00 or 13:00 in the time zone of the fund's domicile. For the Europa Growth Fund, this is 13:00 CET or CEST on Luxembourg trading days.
• The distributor cut-off — distributors typically set their own cut-offs a few hours before the fund cut-off, to give themselves enough time to aggregate and forward the collected orders to the fund. A German distributor might cut off at 10:30 CET, a French distributor at 11:00 CET.

The consequence: a subscription that reaches the distributor at 10:00 CET makes both the distributor cut-off and the fund cut-off and is settled at the same-day NAV. A subscription that reaches the distributor at 12:00 CET misses the distributor cut-off, even though it would have comfortably made the fund cut-off, and is rolled over to the next trading day's NAV. The distributor effectively adds a one-day delay.

How the schema captures the result. FundsXML captures the cut-off decision through the relationship between <TradeDate> and <AccountingDate> on <Flow>. For an order that made the cut-off, both dates are the same day. For an order that missed the distributor cut-off, <TradeDate> is the day the investor submitted the order and <AccountingDate> is the next trading day whose NAV was applied. A consumer that wants to detect "late" orders reads the difference between the two dates. The schema does not label the order as late or on-time — the dates speak for themselves.

The prospectus cut-off time itself is not carried in the core schema on a per-flow basis. Producers that want to transport cut-off metadata for each share class do so through <CustomAttributes> on the share class (Chapter 9), with attribute keys such as CutOffTime (a time value like 13:00) and CutOffTimezone (Europe/Luxembourg). These attributes describe the regime; individual <Flow> records do not repeat them.

7.9.3 Market-Priced Trades, In-Kind Creation, and Exchange-Traded Share Classes

For exchange-traded share classes — UCITS whose units trade on a public market in addition to the NAV-based primary-market channel — the investor-facing trades are executed at the exchange quote, not at the fund's NAV. The creation and redemption process with authorised participants happens in parallel through a NAV-based primary-market channel, but ordinary retail investors in listed classes trade on the exchange at bid/ask prices that reflect, but are not identical to, the underlying NAV.

The FundsXML 4.2.8 core schema does not model exchange-traded flows on <Flow>. A producer running an ETF-style share class has two options:

• Do not emit <Flow> records for exchange trades at all. The exchange-driven creations and redemptions by authorised participants are the only events that meaningfully change the fund's shares outstanding and cash balance, and those events are processed NAV-based through the primary market. Secondary-market exchange trades between investors do not affect the fund's balance sheet and are not reported to the fund.
• Use <CustomAttributes> on the individual <Flow> to annotate the execution channel if the producer's business logic needs it.

For in-kind creation and redemption — where a large institutional subscriber delivers a basket of securities to the fund in exchange for units, rather than cash — the schema approach is to emit a <Flow> with <TransactionType>SUB</TransactionType> and the <TotalValue> expressed as the market value of the delivered basket. The basket itself is not listed on the <Flow>; the positions that arise from the in-kind subscription appear in the next portfolio snapshot (Chapter 6) and are conventionally annotated through <TransactionSubtype>in-kind</TransactionSubtype>.

For negotiated institutional blocks — very large trades priced individually between the fund and a counterparty rather than at the standard NAV — the same mechanism applies: an ordinary <Flow> carrying the negotiated value, with <TransactionSubtype>negotiated</TransactionSubtype> as annotation.

7.9.4 The EMT Regulatory Templates and Cost Disclosure

Chapter 8 treats the FinDatEx regulatory templates that the Europa Growth Fund embeds in the <RegulatoryReportings> root element. The European MiFID Template (EMT) is the relevant one for cost disclosure: it carries the entry costs, exit costs, ongoing charges, performance fees, and transaction costs that an investor in the share class is subject to, in the structure mandated by MiFID II's cost-disclosure rules.

For producers that need to carry entry-load, exit-load, and swing-pricing data in a regulatory context — and that is by far the most common reason for carrying them at all — the EMT fields of Chapter 8 are the authoritative place. For operational purposes (telling a distributor what fee to charge on a given subscription), the data lives in the producer's order-management system and is not carried in the FundsXML delivery at all.

The rule for readers of this chapter: if you expect to find entry-load or swing-pricing fields on a <Flow> record, you will not find them. The core schema captures the outcome of the transaction — the direction, the total value, the dates — and leaves the cost-disclosure mechanics to the regulatory templates.

---

7.10 The Complete Transaction Block for the Europa Growth Fund

The complete transaction data for the reporting period 1–31 March 2026. Because the schema distributes transactions across three containers at two levels of the fund element, the "complete transaction block" is not one listing — it is four separate listings: three <Flows> containers (one per share class) and one <Earnings> container (at the fund-level portfolio). Structured in four subsections.

7.10.1 Overview of the Period

During March 2026 the Europa Growth Fund saw normal transaction activity for a mid-sized European UCITS: seven subscriptions (a net inflow), four redemptions against them, one intra-fund switch, and three dividend income events from European portfolio holdings that paid in Q1. No distribution-paid events — the next one is in mid-May, as §7.7 explained.

The fifteen conceptual events map to sixteen schema records, because the one intra-fund switch is represented as two linked <Flow> entries in two different share classes. The full breakdown is:

• R-EUR-ACC <Flows> (six <Flow> entries): 3 subscriptions (03, 16, 23 March), 2 redemptions (06, 13 March), 1 switch source leg (12 March, paired with the I-EUR-DIST target leg).
• R-CHF-ACC-HEDGED <Flows> (three <Flow> entries): 2 subscriptions (05, 26 March), 1 redemption (19 March). No switch involvement.
• I-EUR-DIST <Flows> (four <Flow> entries): 2 subscriptions (09, 30 March), 1 redemption (20 March), 1 switch target leg (12 March, paired with the R-EUR-ACC source leg).
• Fund-level portfolio <Earnings> (three <Earning> entries): Q1 dividends from Allianz (11 March, German), BNP Paribas (20 March, French), and AstraZeneca (27 March, British).

The events are grouped by container below, not by chronological order across the whole delivery, because the schema nesting demands it. Within each container, entries are listed by date. The complete listing in its fully-populated form has been validated against FundsXML4.xsd as an end-to-end document with a matching AssetMasterData block carrying the three dividend-paying assets.

7.10.2 The R-EUR-ACC Flows Block

The six <Flow> entries inside the R-EUR-ACC share class's <Flows> container. Three subscriptions, two ordinary redemptions, and the source leg of the switch.

<!-- Inside Fund/SingleFund/ShareClasses/ShareClass[ISIN=LU2100000011] -->
<Flows from="2026-03-01" to="2026-03-31">
  <!-- Subscriptions -->
  <Flow>
    <ActionCode>C</ActionCode>
    <TransactionID>EGF-TX-20260303-0001</TransactionID>
    <TradeDate>2026-03-03</TradeDate>
    <AccountingDate>2026-03-03</AccountingDate>
    <SettlementDate>2026-03-05</SettlementDate>
    <ValueDate>2026-03-03</ValueDate>
    <TransactionType>SUB</TransactionType>
    <Units>202.1578</Units>
    <TotalValue><Amount ccy="EUR" isFundCcy="true">25000.00</Amount></TotalValue>
    <Channel>Retail</Channel>
  </Flow>
  <Flow>
    <ActionCode>C</ActionCode>
    <TransactionID>EGF-TX-20260316-0024</TransactionID>
    <TradeDate>2026-03-16</TradeDate>
    <AccountingDate>2026-03-16</AccountingDate>
    <SettlementDate>2026-03-18</SettlementDate>
    <ValueDate>2026-03-16</ValueDate>
    <TransactionType>SUB</TransactionType>
    <Units>80.6852</Units>
    <TotalValue><Amount ccy="EUR" isFundCcy="true">10000.00</Amount></TotalValue>
    <Channel>Retail</Channel>
  </Flow>
  <Flow>
    <ActionCode>C</ActionCode>
    <TransactionID>EGF-TX-20260323-0032</TransactionID>
    <TradeDate>2026-03-23</TradeDate>
    <AccountingDate>2026-03-23</AccountingDate>
    <SettlementDate>2026-03-25</SettlementDate>
    <ValueDate>2026-03-23</ValueDate>
    <TransactionType>SUB</TransactionType>
    <Units>402.4811</Units>
    <TotalValue><Amount ccy="EUR" isFundCcy="true">50000.00</Amount></TotalValue>
    <Channel>Retail</Channel>
  </Flow>
  <!-- Redemptions -->
  <Flow>
    <ActionCode>C</ActionCode>
    <TransactionID>EGF-TX-20260306-0004</TransactionID>
    <TradeDate>2026-03-06</TradeDate>
    <AccountingDate>2026-03-06</AccountingDate>
    <SettlementDate>2026-03-10</SettlementDate>
    <ValueDate>2026-03-06</ValueDate>
    <TransactionType>RED</TransactionType>
    <Units>68.7247</Units>
    <TotalValue><Amount ccy="EUR" isFundCcy="true">8500.00</Amount></TotalValue>
    <Channel>Retail</Channel>
  </Flow>
  <Flow>
    <ActionCode>C</ActionCode>
    <TransactionID>EGF-TX-20260313-0017</TransactionID>
    <TradeDate>2026-03-13</TradeDate>
    <AccountingDate>2026-03-13</AccountingDate>
    <SettlementDate>2026-03-17</SettlementDate>
    <ValueDate>2026-03-13</ValueDate>
    <TransactionType>RED</TransactionType>
    <Units>258.4821</Units>
    <TotalValue><Amount ccy="EUR" isFundCcy="true">32000.00</Amount></TotalValue>
    <Channel>Retail</Channel>
  </Flow>
  <!-- Switch, source leg (paired with EGF-SW-20260312-0007-TGT in the I-EUR-DIST class) -->
  <Flow>
    <ActionCode>C</ActionCode>
    <TransactionID>EGF-SW-20260312-0007-SRC</TransactionID>
    <TradeDate>2026-03-12</TradeDate>
    <AccountingDate>2026-03-12</AccountingDate>
    <SettlementDate>2026-03-16</SettlementDate>
    <ValueDate>2026-03-12</ValueDate>
    <TransactionType>RED</TransactionType>
    <TransactionSubtype>switch — source leg; paired with EGF-SW-20260312-0007-TGT on LU2100000037</TransactionSubtype>
    <Units>404.2156</Units>
    <TotalValue><Amount ccy="EUR" isFundCcy="true">50000.00</Amount></TotalValue>
    <Channel>Intra-fund switch</Channel>
  </Flow>
</Flows>

7.10.3 The R-CHF-ACC-HEDGED Flows Block

Three <Flow> entries inside the R-CHF-ACC-HEDGED share class's <Flows> container. Two subscriptions and one redemption, all in Swiss francs. The <TotalValue> carries two <Amount> children in each entry — one in CHF flagged isShareClassCcy="true", one in EUR flagged isFundCcy="true" — so that consumers reading either currency see a consistent figure.

<!-- Inside Fund/SingleFund/ShareClasses/ShareClass[ISIN=LU2100000029] -->
<Flows from="2026-03-01" to="2026-03-31">
  <Flow>
    <ActionCode>C</ActionCode>
    <TransactionID>EGF-TX-20260305-0003</TransactionID>
    <TradeDate>2026-03-05</TradeDate>
    <AccountingDate>2026-03-05</AccountingDate>
    <SettlementDate>2026-03-09</SettlementDate>
    <ValueDate>2026-03-05</ValueDate>
    <TransactionType>SUB</TransactionType>
    <Units>125.8812</Units>
    <TotalValue>
      <Amount ccy="CHF" isShareClassCcy="true">15000.00</Amount>
      <Amount ccy="EUR" isFundCcy="true">14410.75</Amount>
    </TotalValue>
    <Channel>Retail</Channel>
  </Flow>
  <Flow>
    <ActionCode>C</ActionCode>
    <TransactionID>EGF-TX-20260326-0038</TransactionID>
    <TradeDate>2026-03-26</TradeDate>
    <AccountingDate>2026-03-26</AccountingDate>
    <SettlementDate>2026-03-30</SettlementDate>
    <ValueDate>2026-03-26</ValueDate>
    <TransactionType>SUB</TransactionType>
    <Units>335.6181</Units>
    <TotalValue>
      <Amount ccy="CHF" isShareClassCcy="true">40000.00</Amount>
      <Amount ccy="EUR" isFundCcy="true">38428.00</Amount>
    </TotalValue>
    <Channel>Retail</Channel>
  </Flow>
  <Flow>
    <ActionCode>C</ActionCode>
    <TransactionID>EGF-TX-20260319-0022</TransactionID>
    <TradeDate>2026-03-19</TradeDate>
    <AccountingDate>2026-03-19</AccountingDate>
    <SettlementDate>2026-03-23</SettlementDate>
    <ValueDate>2026-03-19</ValueDate>
    <TransactionType>RED</TransactionType>
    <Units>180.4108</Units>
    <TotalValue>
      <Amount ccy="CHF" isShareClassCcy="true">21500.00</Amount>
      <Amount ccy="EUR" isFundCcy="true">20654.68</Amount>
    </TotalValue>
    <Channel>Retail</Channel>
  </Flow>
</Flows>

7.10.4 The I-EUR-DIST Flows Block

Four <Flow> entries inside the I-EUR-DIST share class's <Flows> container. Two institutional subscriptions, one institutional redemption, and the target leg of the switch.

<!-- Inside Fund/SingleFund/ShareClasses/ShareClass[ISIN=LU2100000037] -->
<Flows from="2026-03-01" to="2026-03-31">
  <Flow>
    <ActionCode>C</ActionCode>
    <TransactionID>EGF-TX-20260309-0005</TransactionID>
    <TradeDate>2026-03-09</TradeDate>
    <AccountingDate>2026-03-09</AccountingDate>
    <SettlementDate>2026-03-11</SettlementDate>
    <ValueDate>2026-03-09</ValueDate>
    <TransactionType>SUB</TransactionType>
    <Units>23202.5830</Units>
    <TotalValue><Amount ccy="EUR" isFundCcy="true">2500000.00</Amount></TotalValue>
    <Channel>Institutional</Channel>
  </Flow>
  <Flow>
    <ActionCode>C</ActionCode>
    <TransactionID>EGF-TX-20260330-0043</TransactionID>
    <TradeDate>2026-03-30</TradeDate>
    <AccountingDate>2026-03-30</AccountingDate>
    <SettlementDate>2026-04-01</SettlementDate>
    <ValueDate>2026-03-30</ValueDate>
    <TransactionType>SUB</TransactionType>
    <Units>46151.2845</Units>
    <TotalValue><Amount ccy="EUR" isFundCcy="true">5000000.00</Amount></TotalValue>
    <Channel>Institutional</Channel>
  </Flow>
  <Flow>
    <ActionCode>C</ActionCode>
    <TransactionID>EGF-TX-20260320-0011</TransactionID>
    <TradeDate>2026-03-20</TradeDate>
    <AccountingDate>2026-03-20</AccountingDate>
    <SettlementDate>2026-03-24</SettlementDate>
    <ValueDate>2026-03-20</ValueDate>
    <TransactionType>RED</TransactionType>
    <Units>15000.0000</Units>
    <TotalValue><Amount ccy="EUR" isFundCcy="true">1617631.50</Amount></TotalValue>
    <Channel>Institutional</Channel>
  </Flow>
  <!-- Switch, target leg (paired with EGF-SW-20260312-0007-SRC in the R-EUR-ACC class) -->
  <Flow>
    <ActionCode>C</ActionCode>
    <TransactionID>EGF-SW-20260312-0007-TGT</TransactionID>
    <TradeDate>2026-03-12</TradeDate>
    <AccountingDate>2026-03-12</AccountingDate>
    <SettlementDate>2026-03-16</SettlementDate>
    <ValueDate>2026-03-12</ValueDate>
    <TransactionType>SUB</TransactionType>
    <TransactionSubtype>switch — target leg; paired with EGF-SW-20260312-0007-SRC on LU2100000011</TransactionSubtype>
    <Units>464.0882</Units>
    <TotalValue><Amount ccy="EUR" isFundCcy="true">50000.00</Amount></TotalValue>
    <Channel>Intra-fund switch</Channel>
  </Flow>
</Flows>

7.10.5 The Fund-Level Portfolio Earnings Block

Three <Earning> entries inside the fund-level <Portfolio>/<Earnings> container. These are the Q1 2026 dividend receipts from three European portfolio holdings, distinguished by source country through the different withholding-tax regimes. The German entry uses WithholdingTaxQuota=26.375 (Germany's standard withholding rate), the French entry uses 25.00 (the France-Luxembourg tax-treaty rate), and the British entry uses 0.00 (the United Kingdom does not withhold tax on dividends paid to non-resident shareholders).

<!-- Inside Fund/FundDynamicData/Portfolios/Portfolio -->
<Earnings from="2026-03-01" to="2026-03-31">
  <Earning>
    <EarningID>EGF-EARN-20260311-0008</EarningID>
    <AssetUniqueID>DE0008404005</AssetUniqueID>
    <EarningKind>Dividend</EarningKind>
    <ClosingDate>2026-03-11</ClosingDate>
    <EntryDate>2026-03-13</EntryDate>
    <ValutaDate>2026-03-13</ValutaDate>
    <EntryCurrency>EUR</EntryCurrency>
    <IncomeCurrency>EUR</IncomeCurrency>
    <EntryValue>
      <Amount ccy="EUR" isFundCcy="true">362830.00</Amount>
    </EntryValue>
    <NominalValueOrUnits>32000</NominalValueOrUnits>
    <PostingText>Allianz SE 2026 annual dividend, net of 26.375% German withholding tax</PostingText>
    <Dividend>
      <DividendPerUnitValue><Amount ccy="EUR">15.40</Amount></DividendPerUnitValue>
      <DividendGrossValue><Amount ccy="EUR" isFundCcy="true">492800.00</Amount></DividendGrossValue>
      <DividendNetValue><Amount ccy="EUR" isFundCcy="true">362830.00</Amount></DividendNetValue>
      <WithholdingTaxValue><Amount ccy="EUR">129970.00</Amount></WithholdingTaxValue>
      <ExDay>2026-03-11</ExDay>
      <PayDay>2026-03-13</PayDay>
      <WithholdingTaxQuota>26.375</WithholdingTaxQuota>
    </Dividend>
  </Earning>
  <Earning>
    <EarningID>EGF-EARN-20260320-0012</EarningID>
    <AssetUniqueID>FR0000131104</AssetUniqueID>
    <EarningKind>Dividend</EarningKind>
    <ClosingDate>2026-03-20</ClosingDate>
    <EntryDate>2026-03-24</EntryDate>
    <ValutaDate>2026-03-24</ValutaDate>
    <EntryCurrency>EUR</EntryCurrency>
    <IncomeCurrency>EUR</IncomeCurrency>
    <EntryValue>
      <Amount ccy="EUR" isFundCcy="true">123750.00</Amount>
    </EntryValue>
    <NominalValueOrUnits>110000</NominalValueOrUnits>
    <PostingText>BNP Paribas Q1 interim dividend, net of 25% French withholding tax</PostingText>
    <Dividend>
      <DividendPerUnitValue><Amount ccy="EUR">1.50</Amount></DividendPerUnitValue>
      <DividendGrossValue><Amount ccy="EUR" isFundCcy="true">165000.00</Amount></DividendGrossValue>
      <DividendNetValue><Amount ccy="EUR" isFundCcy="true">123750.00</Amount></DividendNetValue>
      <WithholdingTaxValue><Amount ccy="EUR">41250.00</Amount></WithholdingTaxValue>
      <ExDay>2026-03-20</ExDay>
      <PayDay>2026-03-24</PayDay>
      <WithholdingTaxQuota>25.00</WithholdingTaxQuota>
    </Dividend>
  </Earning>
  <Earning>
    <EarningID>EGF-EARN-20260327-0015</EarningID>
    <AssetUniqueID>GB0009895292</AssetUniqueID>
    <EarningKind>Dividend</EarningKind>
    <ClosingDate>2026-03-27</ClosingDate>
    <EntryDate>2026-03-31</EntryDate>
    <ValutaDate>2026-03-31</ValutaDate>
    <EntryCurrency>GBP</EntryCurrency>
    <IncomeCurrency>GBP</IncomeCurrency>
    <EntryValue>
      <Amount ccy="GBP">69000.00</Amount>
      <Amount ccy="EUR" isFundCcy="true">81742.50</Amount>
    </EntryValue>
    <NominalValueOrUnits>75000</NominalValueOrUnits>
    <PostingText>AstraZeneca interim dividend, no UK withholding tax on non-resident dividends</PostingText>
    <Dividend>
      <DividendPerUnitValue><Amount ccy="GBP">0.92</Amount></DividendPerUnitValue>
      <DividendGrossValue><Amount ccy="GBP">69000.00</Amount></DividendGrossValue>
      <DividendNetValue><Amount ccy="GBP">69000.00</Amount></DividendNetValue>
      <WithholdingTaxValue><Amount ccy="GBP">0.00</Amount></WithholdingTaxValue>
      <ExDay>2026-03-27</ExDay>
      <PayDay>2026-03-31</PayDay>
      <WithholdingTaxQuota>0.00</WithholdingTaxQuota>
    </Dividend>
  </Earning>
</Earnings>

7.10.6 A Three-Pass Reading

The four blocks are best understood in three passes, one per conceptual group.

First pass — investor-side flows. Eleven <Flow> entries representing seven subscriptions and four redemptions, distributed across the three share classes' <Flows> containers. The net flow is positive: subscriptions total roughly 7.64 million EUR equivalent (counting the CHF figures via the embedded EUR Amounts in <TotalValue>), while redemptions total roughly 1.67 million EUR equivalent. The net inflow is therefore around 6 million EUR for the month. This explains why the SharesOutstanding of all three classes grew between 28 February (roughly 4.01 million shares total) and 31 March (the 1,234,567 + 456,789 + 2,345,678 figures from Chapter 5). The institutional class I-EUR-DIST saw the largest single inflows (a 2.5 million EUR subscription on 9 March and a 5 million EUR subscription on 30 March), consistent with the notion that institutional investors make larger but less frequent allocations than retail investors. None of the redemptions triggered swing pricing, because none of them approached the 2% net-outflow threshold — but as §7.5.2 noted, swing-pricing data does not appear in the schema-level <Flow> records anyway, so a consumer that wants to verify the no-swing condition reads a <CustomAttributes> field on the share class instead.

Second pass — the switch as two linked Flows. One intra-fund switch represented as two <Flow> entries with a -SRC/-TGT <TransactionID> pairing convention. The source leg sits in the R-EUR-ACC class's <Flows> (the fifth entry of §7.10.2's listing) with <TransactionType>RED</TransactionType> and 404.2156 units; the target leg sits in the I-EUR-DIST class's <Flows> (the fourth entry of §7.10.4's listing) with <TransactionType>SUB</TransactionType> and 464.0882 units. Both legs carry the same <TotalValue> of 50,000 EUR. The two <Units> values differ because the two classes have different NAVs, and both are positive — direction comes from <TransactionType>. The pairing convention lives in <TransactionSubtype>, which on each leg names the paired leg's ID. A consumer that walks the document linearly sees the two legs as a redemption and a subscription that happen to net to zero at the fund level; a consumer that recognises the pairing reconstructs the conceptual switch. It is technically unlikely that a 50,000 EUR stake would be allowed to cross into the institutional class (the minimum is 1,000,000 EUR), but the example is retained for structural illustration.

Third pass — income events in the portfolio. Three <Earning> entries inside the fund-level <Portfolio>/<Earnings> container, each representing a Q1 dividend from a different country. Each carries its own withholding-tax regime: 26.375% for Germany (Allianz), 25% for France (BNP Paribas), and 0% for the United Kingdom (AstraZeneca; the United Kingdom does not withhold tax on dividends paid to non-resident shareholders, a peculiarity of UK dividend taxation). The gross amounts total 492,800 EUR + 165,000 EUR + 69,000 GBP ≈ 740,000 EUR equivalent; the net amounts total around 570,000 EUR after withholding. These amounts increase the fund's cash balance and contribute to the Q1 income that will eventually feed the May distribution on the I-EUR-DIST class. Each <Earning> carries an <AssetUniqueID> IDREF pointing at the corresponding entry in <AssetMasterData> (Chapter 6), so that a consumer can join the dividend back to the position that earned it without ambiguity.

The four blocks as shown reconcile internally: the sum of <TotalValue> deltas across the eleven <Flow> entries and the cash inflows from the three <Earning> entries are consistent with the movements in <TotalAssetValues> between the two valuation points. The complete reconciliation — starting from the 28 February state, applying every flow and every earning in these blocks, arriving at the 31 March state — is printed in Appendix D as a worked example, using the validated end-to-end document this chapter is built from.

---

7.11 Common Pitfalls

The following short list captures the mistakes that, in our experience, cause the greatest share of transaction-related production incidents.

• Looking for transactions in the wrong container. A consumer expects investor flows under FundDynamicData and finds nothing, because the real container is Fund/SingleFund/ShareClasses/ShareClass/Flows. Or expects portfolio income events under a share class and finds nothing, because the real container is Fund/FundDynamicData/Portfolios/Portfolio/Earnings. The rule: <Flows> and <Distributions> live on each share class; <Earnings> lives on the fund-level portfolio; there is no fund-level <SingleFundFlows>-style aggregator.
• Negative <Units> on a redemption. A producer treats <Units> as a signed number to indicate direction. The schema explicitly demands positive values: "Number of shares/units bought or sold (should be always positive)." Direction comes from <TransactionType> (SUB or RED), not from the sign of <Units>. A consumer that sums signed units mis-handles the producer's positive-only data and gets the wrong inflow figure.
• Missing <ActionCode>, <AccountingDate>, <TransactionType>, or <TotalValue> on a <Flow>. All four are mandatory in FlowType. A producer that omits any of them fails schema validation at load time. The most common omission is <AccountingDate>, because legacy systems carry only a "trade date" concept and forget to map it to the schema's accounting-date field.
• Switch counted as one transaction in either direction. A consumer sees only the source leg (<TransactionType>RED</TransactionType>) of a switch and reports a redemption to the producer's records, without realising that the matching target leg lives in another share class's <Flows>. The net flow metric is wrongly negative. The rule: a switch is two linked <Flow> entries, and a consumer that wants to detect them looks for the <TransactionSubtype> annotation or for paired <TransactionID> prefixes across share classes.
• AnnouncementDate written as DeclarationDate. A producer migrating from a legacy "declaration date" vocabulary writes <DeclarationDate> on a <Distribution> and fails schema validation. The schema element is <AnnouncementDate>. Similar trap: the schema uses ExDate, RecordDate, PaymentDate as element names — the operational concepts have schema names that do not always match the textbook vocabulary.
• <DividendStatus> missing on a distribution. Mandatory enum (ESTIMATED or OFFICIAL). A producer that forgets it fails validation. A consumer that finds it set to ESTIMATED should expect the same distribution to reappear in a later delivery with OFFICIAL status; treating an ESTIMATED distribution as the final value is a recurring source of investor-statement errors.
• PerShare written without the Total it pairs with. GrossDividendAmount and NetDividendAmount each have an optional <Total> and a mandatory <PerShare>. The structure is gross: <GrossDividendAmount><Total>...</Total><PerShare>...</PerShare></GrossDividendAmount>. A producer that emits <GrossDividendAmount>3.80</GrossDividendAmount> flat (without the inner <PerShare> wrapper) fails validation.
• Distributions confused with earnings. A producer or consumer treats a dividend received from a portfolio holding (an <Earning> in the portfolio) as if it were a distribution paid to investors (a <Distribution> in a share class), or vice versa. The two are economic opposites and live in different containers. The rule: cash flows into the fund go into Portfolio/Earnings; cash flows out of a share class to its investors go into ShareClass/Distributions.
• Withholding tax forgotten on income events. A consumer sums the <DividendGrossValue> fields of <Earning> records without subtracting the <WithholdingTaxValue> and computes the fund's cash balance too high. Reconciliation with the custodian statement fails. The rule: use <EntryValue> (or <DividendNetValue>) for cash reconciliation, <DividendGrossValue> for income analysis.
• <EarningKind> value misspelled. The schema enumeration is Coupon, Dividend, Fund distribution, Interest deposit/giro, Interest swap, Other. Producers that write Fund Distribution (capital D), InterestDeposit, or Interests fail validation. The exact spelling — including the embedded slash and the lowercase second word — is part of the schema.
• <SettlementDate> values treated as trade dates. A consumer archives the <SettlementDate> of a <Flow> as the trade date, and later queries for "which orders came in on day X?" return wrong results. The rule: <TradeDate> for audit and reporting, <AccountingDate> for NAV pricing, <SettlementDate> only for cash movements.
• OrderExecutionType written as a <Flow> child. A producer migrating from another fund-data format writes <OrderExecutionType>AtNAV</OrderExecutionType> and fails schema validation, because no such element exists. The operational concept (forward pricing, cut-offs, in-kind subscription, exchange execution) is not modelled in the core schema; producers that need to carry it use <CustomAttributes> or the regulatory templates of Chapter 8.

---

7.12 Key Takeaways

• Transactions are not centralised in FundsXML. They live in three different containers attached to two different parents: subscriptions and redemptions in ShareClass/Flows/Flow (schema type FlowType), distributions paid to investors in ShareClass/Distributions/Distribution (DistributionType), and income received from portfolio holdings in Portfolio/Earnings/Earning (EarningType). There is no fund-level aggregator container.
• FlowType carries four mandatory children — <ActionCode>, <AccountingDate>, <TransactionType>, <TotalValue> — and a binary <TransactionType> enumeration with only two values: SUB and RED. The schema does not define a third value for switches, distributions, or income; those event types either live in other containers or are modelled as paired SUB/RED records.
• Every <Flow> carries up to four date fields: <TradeDate>, <AccountingDate>, <SettlementDate>, <ValueDate>. Only <AccountingDate> is mandatory. There is no element called EffectiveDate; the legacy textbook effective date maps to <AccountingDate>, the field whose value carries the cut-off decision in the European forward-pricing model.
• <Units> on <Flow> is always positive, by explicit schema convention. Direction comes from <TransactionType>. <TotalValue> is the one mandatory money amount and uses FundAmountType, so it can carry several <Amount> children at once — typically one in the fund's base currency and one in the share-class currency for hedged or non-base-currency classes.
• Switches are not a first-class schema construct. The schema has no Switch value in <TransactionType>; an intra-fund switch is modelled as two linked <Flow> entries, one with RED on the source class and one with SUB on the target class. The convention for linking the two is shared <TransactionID> prefix and matching <TransactionSubtype> annotations. Inter-fund switches use the same pattern across two different <Fund> elements.
• DistributionType (in ShareClass/Distributions) carries seven mandatory children: <ActionCode>, <DividendStatus> (ESTIMATED/OFFICIAL), <ExDate>, <PaymentDate>, <PaymentCurrency>, <GrossDividendAmount>, <NetDividendAmount>. The two amount blocks each contain an optional <Total> and a mandatory <PerShare>. The schema element is <AnnouncementDate>, not the legacy DeclarationDate. There is no DistributionSubType enumeration.
• EarningType (in Portfolio/Earnings) carries five mandatory children: <EarningID>, <EarningKind>, <EntryDate>, <EntryCurrency>, <EntryValue>. <EarningKind> is a six-value enumeration: Coupon, Dividend, Fund distribution, Interest deposit/giro, Interest swap, Other. Each of the first three has a typed sub-block (<Coupon>, <Dividend>, <FundDistribution>) carrying the kind-specific breakdown including withholding-tax fields.
• The <AssetUniqueID> field on an <Earning> is an xs:IDREF pointing at the matching <Asset> in <AssetMasterData> — the same parser-enforced linkage mechanism as <Position>/<UniqueID> from Chapter 6.
• The forward-pricing concepts (cut-off times, swing pricing, entry/exit loads, in-kind creation, exchange execution) are real and operationally important, but the FundsXML 4.2.8 core schema does not model them on <Flow>. Producers that need to carry them use <CustomAttributes> on the share class or the EMT regulatory templates of Chapter 8.
• The Europa Growth Fund's March 2026 transaction block consists of three <Flows> containers (six entries on R-EUR-ACC, three on R-CHF-ACC-HEDGED, four on I-EUR-DIST — sixteen Flow entries in total covering eleven trades and two switch legs) plus three <Earning> entries on the fund-level portfolio. There are no distributions, because the next one does not occur until mid-May.

We have now covered the three transaction containers — ShareClass/Flows, ShareClass/Distributions, and Portfolio/Earnings — together with the per-instrument trade container Portfolio/Transactions that we deferred to Chapter 12. What we have not yet covered is the fifth main area of a FundsXML delivery: RegulatoryReportings, where the five FinDatEx templates live. Chapter 8 opens that area and walks through EMT, EPT, EET, EFT, and TPT — the regulatory disclosures that modern European fund distribution depends on, and the place where many of the operational concepts of §7.9 actually find their FundsXML home.

↑ Top