Unlike some other industry standards, openfunds aims to create a data dictionary or glossary of terms, defining data concepts and values without mandating a structure in which these concepts must be used. There are some partial exceptions to this, such as specific data subsets like Ratios and Exposures, or Corporate Actions data, where openfunds white papers will suggest a template structure, but broadly speaking there is no one openfunds template and file structures should be agreed between senders and recipients of data.

It is important to note that openfunds is a data standard, not a data vendor. openfunds does not receive, store, or disseminate any kind of fund data and is unable to supply such data to anyone. However, many openfunds Members and users are data vendors and will be able to arrange data feeds or other dissemination in openfunds format if they are approached directly.

In general, openfunds aims to release new versions no more than twice a year. Such releases are normally minor releases, where only the second version number changes, the one after the first dot. For instance, the version changes from “1.24” to “1.25“.

On the other hand, there can also be unscheduled releases due to new regulations coming into force on a specific date such as MiFID II, PRIIP etc. Furthermore, as openfunds becomes more useful to fund houses and fund distributors from all over the world, country-specific requirements, which need to be set up in due time could also lead to an early release of new fields.

Apart from minor releases, there also exist major releases and bug fixes. In the following, two examples demonstrate how the version number would change for each release type:

• major release: “1.34″ to “2.00″
• bug fixes/minor additions: “1.25.01” to “1.25.02” (only indicated on the first page of the field list in PDF format)

The third version number is generally not indicated within the file name of the field lists nor mentioned in announcements or headlines.

openfunds understands that new versions always require resources, time and patience. However, we try to provide with our field definitions the possibility to distribute and exchange fund data in a high-qualitative and standardized manner to prevent different solutions of multiple parties for the same problem making it eventually even more complicated.

In order to make upcoming changes of new versions and the development of new openfunds fields as transparent and early accessible as possible, openfunds created a ‘Next Version’ page. This page can be found here and provides you with detailed information of the current status and process of the next openfunds field version.

Yes, all openfunds fields have individual HTML pages that can be reached via replacing [OFID] in the URL https://openfunds.org/[OFID] with their individual field ID. For example, if you would like to link to openfunds description for “OFST160100 Legal Form”, just use the following Hyperlink: https://openfunds.org/OFST160100.

There are several ways to do this:

1) The “No Longer Supported Fields” section of the Current Version page has PDF and Excel files showing only no longer supported fields.

2) In the field list Excel file, available on the same page: either use the Tag column to filter for “No longer supported”, or use the two versioning columns: “Introduced” and “ValidUntil”. These two columns indicate which version was in use when the field was inserted and when it became //No longer supported// respectively.

3) In the field list PDF, available in the same location, use the PDF reader search for the term “//No longer supported” (with the forward slashes, but without the inverted commas).

The various openfunds versions usually have version numbers in the format M.mm(.nn), as listed at previous versions. This means:

– M… a major release number
– mm… a minor release number
– nn.. intermediate releases without field changes (bug fixes or purely new additions)

Within a major release, (same number before the dot) openfunds tries to ensure the most effective backward compatibility possible. (See also: Whitepaper: “Version Management”). Versions with a “0” as the major version number refer to beta releases.

In connection with version numbers, it is important to note that fields with different version numbers can be mixed within a single file, as long as all the fields are valid within the same major release. In other words: when transferring fund data, the version number is attached to individual fields and not to the file itself.

Both FundsXML and openfunds help to automate the exchange of data by making structural and content-related proposals which can be used as common denominators. Whilst FundsXML specifies the file format and thereby draws on the advantages of XML, openfunds accepts a whole array of file formats, including txt, csv, xls(x) as well as XML files. When issues occur, openfunds implicitly assumes that the data are available, or are being processed, in a spreadsheet. openfunds lays particular emphasis on the exact description and definition of the data fields as well as allocation of a unique identifier for each field, which openfunds calls the “OF-ID”.

In practice FundsXML sets itself apart through the possibility of fully automated data transfer, provided both the recipient and the sender have implemented the standard. In contrast, openfunds prioritises a more user friendly, more manual, semi-automated processing and transfer of fund data using standard software.

Whereas FundsXML requires a given structure for data transfer, openfunds recommends a flat structure. Both have their advantages and disadvantages. Whilst FundsXML manages to avoid redundancies in the data transfer by structuring the data, this is not the case with openfunds. On the other hand, XML produces much larger files because they contain a lot of structural information. openfunds files are also easier to read and are transferred using standard software.