This white paper addresses all openfunds fields with the openfunds ID prefix of OFEM or OFEP.
This white paper aims to address the changes that were made to fields related to the European MiFID and PRIIPS Template in v1.26 of openfunds, primarily addressing the ringfencing of these datasets.
Historical approach to regulatory data
EMT 1.0/EPT and openfunds
When data from the European PRIIPs and MiFID templates were originally added to openfunds, this data was treated like any other static data. Fields from the Financial Data Exchange (FinDatEx, then the European Working Group or EWG) templates were matched with existing OFST (openfunds static data) and OFDY (openfunds dynamic data) fields, and new openfunds fields were created where fields in the PRIIPs and MiFID templates did not exist in the openfunds standard. e.g.:
- OFST160040 Type Of EU Directive <-> EMT: 00060_Financial_Instrument_Legal_Structure
- OFST020060 Full Share Class Name <-> EPT: 00050_Portfolio_Name
- OFST024000 SRRI <-> EMT: 04020_Risk_Tolerance_UCITS_Metholodology <-> EPT: 05030_Portfolio_UCITS_SRRI
This created some discrepancies between the openfunds and FinDatEx EMT/EPT definitions of similar fields and concepts, where the fields already existed in openfunds with a slightly different definition or field content.
With the success of the EMT and EPT standards within the market, openfunds has decided to closer align with these EMT/EPT definitions of fields to minimize translation effort between the two standards.
As of 10th December 2020, the new version of the European MiFID template (version 3.0) introduced by FinDatEx will become mandatory for users of the template. In version 1.26 of openfunds, these changes have also been reflected in openfunds to ensure compliance with the latest version of the FinDatEx template. With this change to the template, openfunds decided to change its approach to these and other regulatory templates.
New approach to openfunds regulatory data
Before v1.26, the openfunds static dataset consisted of a “mixed bag” of data, including both ordinary static data and regulatory data such as the contents of the European PRIIPs and MiFID templates.
This mixing of static and regulatory data would mean that static data (such as OFST024000 SRRI) provided by static data teams might be overwritten by data provision by separate regulatory teams providing the same field (in openfunds v1.25 OFST024000 SRRI = 04020_Risk_Tolerance_UCITS_Metholodology) with different data to an openfunds user, causing data fidelity issues and confusion for users.
The major change introduced in v1.26.2 of openfunds (a subset of version 1.26 dealing with changes specific to EMT and EPT data) is the move to treating EMT and EPT data fields as entirely separate from the main openfunds static dataset. This means:
- Introduction of new field ranges for openfunds EMT (OFEM) and openfunds EPT (OFEP) fields;
- Creation of new fields in these ranges for each field in the EMT and EPT, including where these field concepts are already covered by an openfunds static (OFST) field;
- Retirement of any OFST field that was solely required for EMT and EPT data (as these fields will be replaced by the new OFEM and OFEP fields);
- Adjustments to all OFST fields that mentioned EMT or EPT, as these concepts will no longer be taken into consideration for OFST fields.
The advantages of this new approach to these templates will be:
- Smaller distinct datasets with clear purposes;
- Each team responsible for static/EPT/EMT data can own a separate openfunds template, rather than all contributing to a single template;
- No overwriting of fields between static static/EPT/EMT data teams.
A second weakness of openfunds previous approach to regulatory data is the (not always intuitive) translation rules between openfunds and the EMT or EPT. Alongside the ringfencing change, openfunds has taken steps to ensure openfunds regulatory fields (those in OFEM and OFEP ranges) match the FinDatEx version as closely as possible. An example of such a change is shown in the below table.
The advantages of this change will be:
- Minimal effort to translate openfunds to FinDatEx format and vice versa;
- FinDatEx will be mutually compatible with openfunds (cannot currently translate from FinDatEx to openfunds).
The total scope of changes to closer align with EMT and EPT standards in v1.26.2 of openfunds is as follows:
|New Fields (incl. moved fields):||53 (202)|
|Fields moved from OFST… to OFEM… and OFEP…:||149|
|No Longer Supported (incl. moved fields):||49 (198)|
The majority of the changes were straightforward migration of fields from the OFST to the OFEM and OFEP ranges. However, a number of fields had larger changes in order to move from the old openfunds field definition to the new, more EMT/EPT compliant definitions.
One particularly notable example of this is that “narrative” type fields, which will not have language tags in the OFEM and OFEP ranges, as the EMT and EPT to not have such functionality and instead keep the same language throughout a given EMT/EPT document. For example, OFST010300 Investment Objective is a static field that allows a language tag, while OFEP040400 EPT Investment Objective (EPT field 04040_Investment_objective_Portfolio) does not, as the language for openfunds EPT is handled by OFEP040100 EPT Filing Language (EPT field 04010_Reference_Language).
|Title:||Ringfencing: A New Approach for openfunds Regulatory Data|
|Authors:||Charlie Duffin, Michael Partin|
If your firm has a need to reliably send or receive fund data, you are more than welcome to use the openfunds fields and definitions free-of-charge. Interested parties can contact the openfunds association by sending an email to: email@example.com
c/o Balmer-Etienne AG
Tel.: +41 44 286 80 20
If you wish to read or download this white paper as PDF, please click here.