This article explains the difference between the InstrumentId, AssetId, and IssuerId properties and their practical use.

InstrumentId is used to reference relevant data throughout the positions file. For a detailed explanation of InstrumentId as it relates to the XML file, please read the articles Introduction to the XML file and The Relationship Between Assets and Instruments.

InstrumentId should be populated in line with the following in mind:

Obeying these three points is essential when creating the InstrumentId.

FundApps uses AssetId to keep track of each individual holding. Unlike the InstrumentId, the AssetId is not required to be unique globally but within each portfolio. FundApps creates a unique asset identifier by combining the AssetId with the PortfolioId of the portfolio holding the asset. In this way, one specific security can be held across multiple portfolios using the same AssetId.

AssetId should follow these guidelines:

Consistency is needed with the AssetId because it is the unique identifier of a specific position. That means if the AssetId is changed from day T to day T+1, FundApps will interpret that the position held on day T as being completely sold out and the position held on day T+1 was just added to the portfolio. This screenshot illustrates an example of this inconsistency:

In this case, the equity is bought on day one (2021-11-24) and has a Quantity of "10000". On the second day (2021-11-25), this position is increased by 50, and the new position is now "10050". To the untrained eye, that might seem fine; however, by hovering over the orange cell for Quantity, the previous value appears as "0", which is inaccurate. The reason for this is the change in AssetId. FundApps reads the asset with AssetId of "123" as completely sold out, and a new position in the asset with AssetId of "456" was bought on day two.

Because some disclosures trigger based on trades, changing the AssetId can provoke unwanted disclosures. Therefore, it is very important that the AssetId remains consistent across NAV dates.

To ensure that FundApps can maintain continuity in rule results over time, it's critical that each security's issuer/company is identified by a unique identifier (string), not only the issuer's name. Any IssuerId used to identify an issuer/company should not change over time to ensure consistency in results. Please do not use LEI or IssuerName.

The main problem with using a company name as an identifier is that company names may change over time. This may occur due to a merger, acquisition, another corporate action, or a simple name change. If the name was used as an identifier, FundApps could not tie previous results under a company's former name to the new company name. This could lead to incorrect rule results and potentially missed disclosures.

We still ask that you provide the name of the company/issuer in the field IssuerName. For EU government bonds, insert the exact sovereign issuer name from ESMA's list of sovereign issuers. For the SSR EU Bonds: United Kingdom rule insert "United Kingdom." More information about this can be found here.

You can choose the value you use for IssuerId as long as it represents a particular issuer over time.

Consider a case where IssuerId is set to a company name such as DaimlerChrysler. If the IssuerId were subsequently changed to Daimler AG, the previous disclosure results under Daimler Chrysler would not be linked over time with results from Daimler AG because FundApps would view them as separate issuers.

This may result in missed or incorrect disclosures as Daimler AG would appear as a "new" issuer.

However, if IssuerId were set to a specific value, e.g. "00DE0391201" for DaimlerChrysler, even after the demerger resulting in a name change to Daimler AG, FundApps would view it as the same company (as identified by its unchanged IssuerId) rather than a new one. In this case, users could conveniently change the IssuerName to clearly identify the same IssuerId of "00DE0391201" as being either DaimlerChrysler or Daimler AG.