FAQ

openfunds version numbers generally follow the pattern M.mm(.n). M refers to the major release, mm to the minor release, and n to intermediate releases such as bug fixes or minor additions.

Within the same major release, openfunds aims to maintain as much backward compatibility as possible. A major release introduces more substantial changes, while regular minor releases usually add or adjust fields within the existing framework.

In connection with version numbers, it is important to note that fields with different version numbers can be mixed within a single data transmission, as long as all the fields are currently valid and part of the most recent openfunds field list. In other words: when transferring fund data, the version number is attached to individual fields and not to the transmission or data file itself.

There are several ways to identify fields that are currently deprecated and scheduled to be removed in the next major release:

– The “No Longer Supported Fields” section on the Current Version page provides PDF and Excel files listing all fields that are currently deprecated and expected to be removed in the next major release.

– In the full field list Excel file, available on the same page, you can use the two versioning columns “Introduced” and “ValidUntil”. These columns show the version in which a field was introduced and the version until which it remains valid.

Fields with a ValidUntil entry are no longer recommended for implementation. In many cases, the field description also points to a replacement field or explains why the field has been put on the retirement path.

New openfunds versions and field changes are published on the website, including the Current Version, Next Version, Previous Versions, Roadmap and changelog areas. Users can also subscribe to the openfunds mailing list through the contact page to receive updates.

Yes. Individual openfunds fields have dedicated HTML pages that can be accessed directly by replacing [OFID] in the URL https://openfunds.org/[OFID] with the relevant openfunds field ID. For example, the field description for OFST160100 “Legal Form” can be accessed via https://openfunds.org/OFST160100.

The intention is that users can implement these direct links in their in-house systems, so that the relevant openfunds field definition is always immediately available. This is particularly useful where an internal database, data management system or user interface is based on openfunds, as users can access the official definition, permitted values and explanatory information directly from the system they are working in.

openfunds interacts with other fund industry and regulatory standards, including FinDatEx and related regulatory templates. Where useful, openfunds aims to incorporate or align with such templates – for example the European PRIIPs Template (EPT) or the European MiFID Template (EMT) – by making their data points available as part of the openfunds field dictionary.

Where a fixed external template structure exists, openfunds usually applies a ring-fenced, dedicated field range for that template. For example, the EMT fields are represented in the dedicated OFEM field range. This approach allows openfunds to integrate regulatory or industry template content while keeping it clearly identifiable as a specific subset of the broader openfunds standard.

Where such external templates are incorporated into openfunds, users still need to determine which internal master data, raw data or calculated data points should be used to populate the relevant template fields. Many of these templates are regulatory in nature and require specific knowledge both of the organisation’s internal data landscape and of the applicable regulatory interpretation. For this reason, openfunds generally does not prescribe a definitive translation logic from, for example, static fund data into templates such as the EMT, EPT or EET. The responsibility for ensuring that the correct underlying data is used remains with the transmitting party.

Both openfunds and FundsXML support more efficient fund data exchange, but they focus on different and complementary aspects. FundsXML provides a structured XML-based exchange format for fund data workflows, while openfunds provides a common vocabulary with precise field definitions, unique field identifiers, permitted values and explanatory guidance. openfunds can be used across various technical formats, including Excel, CSV, TXT, JSON, XML or API-based connections.

In simplified terms, FundsXML is more prescriptive about the technical structure of the data file, whereas openfunds focuses on the semantic definition and interpretation of the underlying data fields. Used together, the two standards can help reduce ambiguity, improve interoperability and support more automated and efficient data exchange between market participants.

openfunds and FundsXML are therefore considered complementary rather than competing standards. The two initiatives are closely aligned and collaborate regularly, including through joint industry events and ongoing exchange on how fund data standards can support a more transparent, standardised and efficient fund data environment across Europe.

You can engage with openfunds by contacting the business office, subscribing to the mailing list, joining discussions or applying for a membership. The contact email is businessoffice@openfunds.org.

For working groups, please contact us so we can connect you with the relevant chairperson.

Membership allows organisations to participate actively in the openfunds community and contribute to the further development of the standard. Members can engage in discussions on field development, data quality, interoperability, regulatory changes and practical implementation needs across the fund industry.

In addition, active members can use internal openfunds field range blocks, which allow them to define internal fields for their exclusive use. This can be particularly useful for organisations that adopt openfunds as part of their internal data model or data storage architecture, as it provides additional flexibility. Internal fields are not strictly tied to the regular openfunds release cycles.

Members also have access to a dedicated logged-in section of the openfunds website, where additional materials and resources are made available. These include recordings of deep-dive sessions and webinars, material used in round tables and other member-specific content.

Becoming an openfunds member is therefore especially relevant for organisations that regularly send, receive, validate or distribute fund data and want to help shape a common industry standard.