The EU regulation No 1286/2014 of 26 November 2014 on key information documents for packaged retail and insurance-based investment products (PRIIPs) requires that private investors are provided with a Key Information Document (PRIIP KID) for their investments. A KID should contain essential information of interest to the private investor. The main factors are:

– Risk level of the product
– Maximum possible loss
– Costs over time

The KID should foster the understanding of the products and facilitate comparisons of different products.

In order to create a PRIIP KID from a database that is able to export openfunds fields, openfunds has created a Sample PRIIP KID including openfunds fields where needed. Each field in the sample links to the according field description.

In general, openfunds aims to release new versions not 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: “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 ‘Next Version’. This site can be found here and provides you with detailed information of the current status and process of the next openfunds field version.

Yes, there is. For example, if you would like to link to openfunds description for “OFST160100 Legal Form”, just use the following Hyperlink: http://openfunds.org/OFST160100.

There are two ways to do this:

1) Under the “Fields” tab, open the “openfunds fields v…” PDF and in the PDF reader search for the term “//No longer supported.//” (with the forward slashes, but without the inverted commas).

2) Alternatively, you can open the Excel file from the same location. On the right hand side are two 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.

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 new fields (bug fixes)

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.

This very much depends on the flexibility of your IT situation. If it is quite flexible and can easily be expanded with new fields, it is worth using openfunds from an early stage, not least because you are probably already filling spreadsheets built on the openfunds standard.

If implementing new fields causes difficulties, it would be better to wait for Version 1.0 as the release cycles of new openfunds versions will be considerably longer after that.

Beta versions, easily recognized by a version number under 1.00, differ from later versions in several ways. Here are the key differences:
– until version 1.00, the number of fields still being incorporated will be relatively high
– new versions will come out in relatively quick succession until version 1.00.
– as a result, there may be some fields with the status “//No longer supported…”.
– before version 1.00 there may be compatibility issues when using successive versions of the field.

Although there will be regular updates after the release of version 1.00, they will be less frequent. Please also be aware that the change from a beta version to version 1.00, so from all the versions with a zero before the dot, will be a “major release”. This affects in particular the “//No longer supported…//” fields, which, after this leap in the releases, will no longer appear in the descriptions; their OF ID will, however, not be overwritten by other fields.

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.