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.
...
For floating aggregates, if a security belongs to node A in source 1, and node B in source 2, then the CIDX build assigns the security based on the alphabetical entity ID in order of source 1 and source 2 (the security commit process would not fail). With this enhancement, the security will would be committed at multiple nodes under ‘SP’ instance , if the option is chosen on user interface.
...
If SS or SP is chosen as security type for the source entities, then the target could be either SS or SP. If the source entities have overlapping securities with L and S records, and if these securities are assigned to multiple nodes in the target dictionary, then the position by strategy build for the CIDX would fail. If SP is enabled, then the security under multiple nodes along with strategy codes would be committed under SP.
...
If SP is chosen as the security type for source entities, then the target could be either SS or SP. The CIDX build for the security would work work for SS if securities are not part of multiple nodes in the target dictionary.
...
The Target entity is built and supported only for the same type of input underlying source entities. For example, If if Source 1 has S, and Source 2 has SS the build will fail.
...
Use single position and build single position is the default legacy option. There is a limitation of the build failing if the security is part of multiple nodes in the target dictionary.
Build SP/SS from S/SS/SP without LS Indicator in the
...
Grouping Rule
If you do not use the Long Short Indicator in the grouping rule and intend to build a SP/SS Perf_summary type from S/SS/SP. Then , then based on the underlying source entity security level weights the system assumes the positive weights as a long strategy and the negative weights as short strategy and . The system assigns the strategy detail ID accordingly to it and does performs the CIDX build process with SP/SS. The SP will be able to commit commits even if the same security is part of multiple nodes on the same day. If the same security is part of multiple nodes in the target dictionary on the same day, then the SS will fail.
Build SP/SS from S/SS/SP with LS Indicator in the
...
Grouping Rule
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 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 blended benchmarkbenchmarks, if Source 1 has Apple in equities and source 2 has Apple in bonds on the same day that the target dictionary will have Apple in both nodes and S, SS will fail. In this case the SP type commit will build showing apple under the equity and fixed income buckets in the target.
...
Use Single position build single position (Legacy S). In the case of floating aggregates, if a security belongs to node A in source 1 and node B in source 2, then the CIDX build assigns the security based on the the alphabetical order of source Entity Id’s IDs, the security commit process would not fail.
Build SP/SS from S/SS/SP without LS Indicator in the Grouping Rule
If you do not use the Long Short Indicator in the grouping rule and intend to build a SP/SS Perf_summary type from S/SS/SP. Then , then based on the underlying source entity security level weights, the system assumes the positive weights as long strategy and the negative weights as short strategy. The system assigns the strategy detail ID accordingly and does performs the CIDX build process with SP/SS. The SP will be able to commit even if the same security is part of multiple nodes on the same day.
...