FundsXML Schema OverviewStructured reference for elements, types, and enumerations

This appendix is a structured reference to the FundsXML 4.2 schema (version 4.2.8 as of the time of writing). Chapters 4 through 8 introduced the same material narratively and with deliberate pedagogical simplifications; this appendix gives the authoritative structural view. Where the narrative chapters presented simplified element names or paths for teaching purposes, the tables below give the real schema names, types, cardinalities, and enumeration values.

Scope. The schema defines well over six hundred complex types. Most of those exist to model edge cases — specific corporate actions, niche asset classes, country-specific disclosures — and are rarely touched by a typical producer pipeline. This appendix covers the curated subset that every producer and consumer implementation encounters: the top-level structure, the ControlData envelope, the core Fund and FundStaticData/FundDynamicData blocks, the Portfolio and Position model, the Transactions model, the RegulatoryReportings block, the common reusable types, and the extension mechanisms. A full schema browser (the FreeXmlToolkit XSD view from Chapter 11, or an online schema viewer) should be consulted for anything beyond this subset.

Conventions.

• Cardinality is given as 1..1 (required, exactly one), 0..1 (optional), 0..n (any number including zero), or 1..n (at least one).
• Type is the schema type name where the element references a named type; simple built-in types (xs:date, xs:decimal, xs:boolean, xs:dateTime, xs:string, etc.) are shown with the xs: prefix.
• ⚑ marks enumerated values. For short enumerations the full list is shown inline; for longer ones the list is given in §C.7.
• ⊕ marks extension points (places where CustomAttributes or CountrySpecificData may be used).
• All element and type names are case-sensitive exactly as written. FundsXML does not use a target namespace, so the names below appear unprefixed in instance documents.

C.1 Top-Level Structure

The root element is FundsXML4. Its children form the main content blocks of the document. ControlData is mandatory; everything else is optional, and a valid document may contain only ControlData together with one or more of the optional blocks appropriate to the delivery's purpose.

Note one detail that is occasionally surprising: RegulatoryReportings lives at the document root, not inside each Fund. A delivery that covers multiple funds with regulatory reporting data places the reporting block once at the top level, with internal references tying each report to the relevant fund.

C.2 ControlData Block

ControlData is the envelope metadata of every FundsXML delivery. Every consumer inspects ControlData first to decide how to handle the incoming document: who sent it, when it was generated, what operation it represents, and which earlier delivery (if any) it relates to.

C.2.1 Direct Children of ControlData

C.2.2 DataSupplierType

Note that DataSupplierType does not contain an LEI field directly; the supplier is identified by the country-scoped Short code, with the legal name as a human-readable label.

C.2.3 ModuleUsage Enumeration

ControlData/ModuleUsage/Module/Name allows the producer to declare which schema modules the delivery exercises, so that consumers can skip parsing blocks that are not present. Valid values are:

AssetMasterData · AssetMgmtCompDynData · CountrySpecificData_AT · CountrySpecificData_DE · CountrySpecificData_DK · CountrySpecificData_FR · CountrySpecificData_LU · CountrySpecificData_NL · FundDynamicData · FundStaticData · PortfolioData · RegulatoryReporting_EMIR · RegulatoryReporting_EMT · RegulatoryReporting_KIID · RegulatoryReporting_PRIIPS · RegulatoryReporting_SolvencyII · ShareClassData · TransactionData

C.2.4 RelatedDocumentIDs

RelatedDocumentIDs
  └── RelatedDocumentID (Text128Type) — 1..n

A single RelatedDocumentIDs element contains one or more RelatedDocumentID children, each of which is a UniqueDocumentID from a previous delivery. DELETE operations must specify which delivery is being retracted via this element; AMEND operations may optionally specify which delivery they supersede.

C.3 Fund Block

Funds is a container with exactly one child element: Fund, which appears once per fund described by the delivery.

Funds
  └── Fund (FundType) — 1..n

C.3.1 FundType — Direct Children

The SingleFund / Subfunds choice reflects the umbrella-structure distinction: a standalone fund uses SingleFund (which holds ShareClasses and optional Segments); an umbrella fund uses Subfunds (which holds one or more Subfund elements, each with its own share classes and segments).

C.3.2 NamesType

C.3.3 FundStaticDataType — Major Children

FundStaticData is large (roughly twenty direct children plus nested structures). The elements a typical producer populates are:

C.3.4 FundDynamicDataType

FundDynamicData is surprisingly compact — it has only three direct children, each of which contains the real complexity:

C.3.5 TotalAssetValueType

C.3.6 SingleFundType

C.3.7 ShareClassType — Major Children

A share class has its own identifiers, names, currency, and a detailed set of dynamic data. The major children are:

C.4 Portfolio Block

The portfolio block lives inside FundDynamicData/Portfolios. Each Portfolio element represents a snapshot of holdings at a specific valuation date.

C.4.1 PortfolioType

C.4.2 PositionType — Major Children

C.4.3 Position Instrument Coverage

A Position element carries instrument-type-specific data in one of several optional sub-elements. The sub-element used depends on the AssetType of the referenced asset in AssetMasterData. The most-used sub-elements are:

C.4.4 AssetMasterData and AssetType

AssetMasterData/Asset is the reference data block. Each asset carries a UniqueID (schema type xs:ID) that position elements reference via xs:IDREF.

The AssetType enumeration uses two-character codes:

C.5 Transactions

Portfolio/Transactions contains a list of Transaction elements. Each transaction has a unique TransactionID (enforced by a schema-level key constraint on the container) and one of five possible kinds.

C.5.1 TransactionType — Major Children

Note that the TransactionKind enumeration has exactly five values. The narrative in Chapter 7 used pedagogical labels (SUBSCRIPTION, REDEMPTION, etc.) that do not appear in the real schema — investor flows are modelled at the share-class level, not as portfolio transactions. The schema-accurate distinction is: Transaction covers portfolio trading activity; investor flows are captured elsewhere in the share-class dynamic data.

C.5.2 EarningsType

Portfolio/Earnings carries coupons, dividends, and distributions resulting from portfolio positions. The block is attributed with from and to dates that bound the reporting period. The underlying EarningsType carries per-position earnings entries with amounts, dates, and tax treatment; the structure is too detailed for this overview — consult the schema browser if you need to populate it.

C.6 RegulatoryReportings and FinDatEx Templates

RegulatoryReportings at the document root has exactly two children:

The terminology reflects the distinction between reports that flow directly to regulators (direct) and reports that flow through distributors or insurance-company intermediaries (indirect).

C.6.1 DirectReporting Children

Each template version is a distinct element with its own type. A producer emits one of the EMT versions and one of the EET versions — typically the most recent — and consumers accept whichever versions their systems support. The multiple versions enable the gradual cross-ecosystem upgrade cycle that Chapter 13 described.

C.6.2 IndirectReporting Children

The PRIIPS element models both the EPT (European PRIIPs Template) used by distributors and the CEPT (Comfort EPT) used for review before publication. Newer EPT versions live in their own elements as they are published.

C.6.3 Template Coverage

The internal structure of each FinDatEx template — the specific fields, enumerations, and value ranges — is published by FinDatEx and embedded in FundsXML. Each template has between 60 and 180 individual fields, far too many to enumerate here. Chapter 8 introduced the purpose and high-level structure of each template; for field-level detail, consult the FinDatEx specification for the relevant template version.

C.7 Common Types and Enumerations

C.7.1 AmountType and FundAmountType

AmountType
  └── Amount (xs:decimal) — 1..n
       └── @ccy (ISOCurrencyCodeType, required) — the currency code

AmountType can carry the same amount in multiple currencies (one Amount per currency, distinguished by the ccy attribute). FundAmountType is a variant used within fund- and portfolio-level values where the amount always includes one representation in the fund's base currency.

C.7.2 IdentifiersType

The IdentifiersType is used wherever a fund, share class, or instrument is identified. The major children are:

All identifier fields are optional; at least one is typically populated.

C.7.3 Core Enumerations

DataOperation (in ControlData/DataOperation):

TotalAssetNature (in TotalAssetValue/TotalAssetNature):

TransactionKind (in Transaction/TransactionKind):

OpenClosedEnded (in FundStaticData/OpenClosedEnded):

SFDRProductType (in FundStaticData/SFDRProductType):

C.7.4 Listed Legal Structure Enumeration

FundStaticData/ListedLegalStructure uses these 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 · SPV

If none of these fits, use UnlistedLegalStructure with free text.

C.7.5 Documents Block

Documents/Document represents references to (or embedded content of) fund-related documents. The Type/ListedType enumeration is:

Other document types are supported via Type/UnlistedType (free text). Documents are typically referenced by URL; inline content is also supported but uncommon.

C.7.6 Reusable Text Types

The schema defines several Text…Type simple types that restrict element content by length:

C.8 Extension Points

C.8.1 CustomAttributes

The CustomAttributes element uses AttributesType, the standard extension mechanism for producer-specific data that does not fit into any standard element. It is permitted inside ControlData, FundStaticData, and many other places throughout the schema.

CustomAttributes (AttributesType)
  └── Attribute — 1..n
        ├── Name (Text256Type) — 1..1
        ├── Type (enum T/N/D/B) — 1..1
        └── (choice) — 1..1
              ├── ValueText (xs:string)
              ├── ValueNumber (xs:decimal)
              ├── ValueDate (xs:date)
              └── ValueBoolean (xs:boolean)

The Type indicator and the chosen Value* element must agree: Type="T" pairs with ValueText, Type="N" with ValueNumber, Type="D" with ValueDate, Type="B" with ValueBoolean.

Use CustomAttributes sparingly. The first question before adding one should always be whether a standard element already exists; the second question should be whether the data belongs in the delivery at all. Permanent project conventions for naming the Name field (for example a {producer}.{domain}.{fieldname} scheme) prevent collisions between projects.

C.8.2 CountrySpecificData

CountrySpecificData appears at several levels of the schema and allows country-specific extensions structured by ISO country code. The main locations are:

Within each of these, the sub-elements are named by ISO country code (AT, DE, DK, FR, LU, NL, and others as they are added). Each country sub-element has its own type that defines what country-specific structure is permitted. Country extensions are typically used for regulatory disclosures specific to one distribution country that do not fit into the FinDatEx templates.

C.9 Schema Version Notes

This appendix documents FundsXML schema version 4.2.8, the version current as of the book's writing in early 2026. The 4.2 minor-version series has been stable since 2019 and is backward-compatible within the series: a document valid against 4.2.0 is also valid against 4.2.8 unless it exercises an element that has been deprecated between the two versions. Producers upgrading between minor versions should consult the changelog published by the FundsXML association for the specific release they are moving to.

Earlier major versions (3.x and prior) are no longer maintained; the 4.0 transition was made many years ago and most elements in the book's target population predate the transition. Anticipated 2026 releases (4.2.9 is expected in November 2026, per the ongoing release cadence) are likely to add new fields to EET and EMT as FinDatEx publishes updated templates, but the structural overview presented in this appendix is expected to remain accurate for the foreseeable future.