A custom blended benchmark consists of underlying source entities based on weights, rates of return, and entity assignments at node levels. The process for defining custom benchmark structures and generating the performance data, returns, and weights is generally the same across all types of custom benchmarks. The custom structures that you can define and the source data required to build the custom benchmark data can differ depending on the custom benchmark type.
This section describes the Build Security Level feature used to define Blended Weighted, Floating Weight, Floating Aggregate, and Currency Conversion custom benchmarks.
For more information on creating these types of benchmarks, see:
...
If you use the Long Short Indicator in the grouping rule and intend to build a SP/SS Perf_summary type from S/SS/SP, then the strategy_detail_id Id is assigned based on the node to which the source index is attached. The source index will be part of that strategy. Assume we have two strategies Core and Tactical: you can assign one index under the core strategy and another index under the tactical strategy and build the SS/ SP perf summary types. If the same security is part of multiple nodes in the target dictionary on the same day under but different strategies (strategy detail ID), then the SS build option will not fail.
...
In the very same example, if we have the LS Indicator in the grouping rule with 2 strategies like core and tactical, and source 1 is assigned to core, and source 2 is assigned to tactical, then the SS commit will not fail as they fall under different strategy detail ID on the same day. The SP type build will be successful.
Examples:
In Floating weighted benchmark if Source 1 has, Apple in Hardware and HP in Software and Source 2 has Apple in Software and HP in Hardware.
A Single position to Single position (Legacy), build will not fail. Apple and HP from both sources get aggregated and gets assigned under the node based alphabetical sort order of both source entities.
In the same example if the user does not have the LS indicator in the grouping rule and intends to build SS from S/SS , then based on underlying weights the strategy detail gets assigned and the build gets completed by aggregating the securities if Long only or showing separately if they are Long and Short as they get the strategy detail assigned based on the weights. The node assignment will follow the sort order process of source entity ids. In the same example if the user intends to build SP then both Apple and HP long and short positions will be displayed under both the nodes Hardware and Software.
In the very same example, if we have the LS Indicator in the grouping rule with 2 strategies like core and tactical and source 1 is assigned to core and source 2 is assigned to tactical.
In the above example if the user builds a S to S then all the securities gets assigned under the Core node as we do not have any strategy detail, all securities gets assigned under the Core and Tactical does not have any securities assigned node and build does not fail.
In the above example if the user builds SS from SS/S then all the securities gets assigned under the Core node and Tactical nodes and in this case both nodes are under different strategy detail id the securities get displayed as under the core and tactical nodes as they were in their respective sources.
SP type build will show both the securities under both the nodes.
Possible Scenarios for Floating Aggregate CIDX Benchmark Type
...