Ambiguity of Empty Fields

Static versus dynamic aspect

This whitepaper looks at the static aspect of empty fields, i.e. the way in which empty fields are interpreted in an existing database or in an export file. This aspect is different from the exchange of data, or the dynamic aspect, whereby empty fields regularly result in data being deleted.

Important note: openfunds follows a data mirroring model, which involves exporting data from a database and importing it into a second database, effectively producing a copy of the original data. In other words, empty fields in the original database will result in empty fields in the target database. A way in which this can be avoided is described in a separate article.

Missing values

Fund databases very often contain missing values. When data is exported to a spreadsheet, missing values are represented by empty fields. Missing data can have far-reaching consequences and can prevent investors from investing in a fund. However, even if it does not come to that, empty fields will frequently result in additional work and costs as the reason for missing data is unclear. Data or values can be missing for four different reasons:

  • unknown

The current value is unknown to the data provider—typically the fund company or a service provider—and so the field is left empty. This situation is immediately apparent but often causes problems in practice as it raises recurring questions as to why the value is missing and when it can be provided. Therefore, for many fields it makes sense to distinguish between “unknown” and “not available”.

  • not available

Like “unknown”, “not available” indicates that there is currently no value for this field. An example of this might be a TER Including Performance Fee (OFST452120), which a fund company is unable to provide because it does not currently calculate this value and has no plan to do so in the foreseeable future.

  • not applicable

This, too, refers to empty fields. Unlike the two scenarios described above, no value can be provided, for example if such values do not apply to a given fund type, as is often the case for pure ETF fields. If such a field is requested for mutual funds, the only possible output is an empty field. However, in this case, an empty field is to be interpreted as “not applicable”.

  • not for disclosure

Unlike the three scenarios above, when empty fields are marked as “not for disclosure”, this basically indicates that a value is available but cannot be disclosed. Therefore, there are essentially two options for data transfer: 1) the value can be provided and marked as “not for disclosure” in a linked field (Availability), or 2) the value is not provided in the first place and marked as “not for disclosure” in the linked field.

Implementation in openfunds

In practice, there are very few fields with “not for disclosure” status. Situations frequently arise, however, where a data recipient might like to know whether or not currently missing values will be available in the future (status “unknown” versus statuses “not available”, “not applicable” or “not for disclosure”). For this reason, openfunds adopts an approach that provides user-friendliness while introducing additional fields only when absolutely necessary.

1. In General openfunds interprets an empty field as “unknown“.
This applies to all field types (numeric, text and Boolean etc.).

2. If that is not sufficient (i.e. if a distinction is required between “unknown” and “not available”), the field in question has a Boolean field added on the side.

This is recognizable because the Boolean field typically includes “Has …xyz…”, with “…xyz…” appearing in the separate field. Examples:

  • “OFST001890 Has Collateral Manager” and “OFST001900 Collateral Manager Name”
  • “OFST6100XX Has Country Representative” and OFST6102XX Country Representative Name”
  • “OFST6105XX Has Country Paying Agent” and OFST6107XX Country Paying Agent Name”

3. If the “not for disclosure” status also needs to be specified, an additional selection field (“… Availability”) is added instead of the Boolean field.
The Availability field typically allows the following attributes:

  • yes

A value is present in the linked field.

  • no

Instead of simply specifying “no”, one of the two following values should be selected:

  • no, not available

The fund provider is currently providing no value and does not expect to do so in the foreseeable future.

  • no, not applicable

In most cases, this value can be derived from one or several other fields; However, it should be specified here as well.

  • yes, but value shouldn’t be disclosed

Here, openfunds allows the choice of whether or not to enter a value in the linked field.

  • empty (=unknown)

An empty Availability field indicates that the data sender does not know whether or not a field should contain a value.


In openfunds, empty fields can almost always be interpreted as “unknown”. However, as there are fields requiring further specification of the “unknown” attribute, openfunds completes the individual fields by linking them with a Boolean field or—occasionally—with an Availability field.

All openfunds users need to do is read the descriptions of the linked fields. The information above is provided solely to explain the theoretical framework.

Document Information


The Ambiguity of Empty Fields






Michael Partin

Revision History








Added versioning details






If you have any questions about the new data type or difficulties with implementation please contact us at

Joining openfunds

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:
c/o Balmer-Etienne AG
Bederstrasse 66
CH-8002 Zurich
Tel.: +41 44 286 80 20

If you wish to read or download this white paper as PDF, please click here.