A question that we often receive during implementation is, "What is the best approach for supplying index data for my index derivatives?" We are aware that supplying static security data for ALL constituents of the S&P 500 index, for example, as well as constituent weights, can be very costly.

The big question is, what do you get for the additional cost vs. the additional risks associated with not supplying the data at all? This article will describe various approaches to supplying the index constituent weightings and static data and describe the risks associated with each approach.

The most conservative and recommended approach is to supply all data on all index constituents. This will ensure that in all jurisdictions where index positions are disclosable, the index constituents are picked up as prescribed by the regulation and aggregated with potential direct holdings in the relevant equity positions, ensuring that no disclosures are missed.

Risks: None. From a regulatory point of view, this is definitely the best approach and will secure the most accurate results and disclosure alerts. This gets the FundApps recommendation badge!

Another approach to take is to only supply weightings on index constituents that are already held as direct holdings. This should impose no additional cost on the static security data under the assumption that the static data is already supplied on the directly held equity. However, there might be a cost associated with providing the weightings on the constituents. Supplying these weightings will make sure that in all rules where the direct equities are picked up, the index position will be aggregated into that position if required by the regulation.

Risks: This approach's risk is that a position held in an index derivative alone is enough to trigger a threshold. Many would see this risk as low, especially when the index underlying the derivative is one of the major indices. If a large position is taken in a small-cap index with few constituents (hence large weightings), then the probability of a disclosure obligation goes up. This is something to keep in mind if following this approach.

The last approach is to not provide any index data at all, which will cost nothing. Naturally, this approach also has the largest risks.

Risks: The risks are the same as with the Semi-Conservative approach, with the addition of whenever an obligation to disclose arises from a position held in direct equities, FundApps is not able to aggregate the index constituent into that result, which means that the percentage calculated will be incorrect, given that the index position should have indeed been included. This could further mean that if a rule monitors a 5% threshold and 4.95% is held via direct equities, then a position in an index could easily be what would have taken the aggregated position over the threshold, and that would, of course, not been flagged, as FundApps has not been provided with the index position.

If you provide index data as Weighting, there is no validation regarding the sum of the weighting of the index constituents. So if there are five components, four of which have a weighting of 20% and the fifth having 30%, for a total of 110%, this would pass validation.

We expect Weighting to be approximately equal to:

i.e., the value of the composite's position in the component divided by the value of the composite, where value is defined as Quantity * Price. We expect this to be the same whether the component shares are held long or short. This means that, in composites that use leverage or trade at a discount to NAV and potentially those with short components, the weightings may not add up to 1 (and could often be more than 1).

For example, consider an ETF with 283,645 shares of APPL as a constituent with a close price of $221.72. Assuming that the close price of the ETF is $62.54 with 23,050,002 shares outstanding, we expect the approximate weight of APPL in the ETF to be:

We expect this to be declared as Weighting=“0.0436” in the position file. This value should align closely with the standard index weightings.
​

Here is an XML example of an index made up of two components with a 50:50 weighting, which should be reflected in the file as 0.5. The correct format and data attributes to include for this property are contained in the docs page, which indicates that this should be included as a decimal value, as indicated above.

If you are providing index data as WeightingQuantity, the sum of the WeightingQuantity * Constituent Price must be < Index Price. There is no validation with regard to the sum of the value of the constituents of an index.

The important properties to include in your file for the index constituents are their respective weight and the InstrumentId for each component. See here for a sample XML for an option on an index.

When filtering by AssetName within the Entity Assets view (Portfolios & Entities > LastData), you will see the security held in the index, but there will not necessarily be an indication that this security is held in an index. The only way to identify that an index holds this security is by viewing the AssetId.

In Question 6.9 of its Q&As (found here), ESMA states that it understands "publicly available information" on an index, a basket of securities, or ETF composition as information which is easy to access on the market operator's or issuer's website and which is obtainable free of charge. Calculations are based on publicly available information. In practice, this means that market participants should use the most recent publicly available information for look-through purposes, but there is no obligation to obtain information on a real-time basis. "Acting reasonably" relates only to obtaining information about the composition and not to how investors process that information for conducting the calculation of the net short position.