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.
...
The build security level options (Perf_Summ_Type - “S”) now include includes Perf_summ_type S and Perf_Summ Types – SS and SP. The Custom Index Module can process security type returns like SS and SP for the following options: Blended Weighted, Floating Weight, Floating Aggregate and Currency Conversion CIDX benchmark types.
...
CIDX types like blended, floating weight, and floating aggregate require security returns from multiple source entities. With floating weight and blended benchmarks, if there are overlapping securities across nodes in the target dictionary, the security commit process fails.This This can be overcome resolved by committing Position by Strategy and Dictionary Classification (SP) records, which involves committing the same security returns under multiple nodes in the target dictionary. In addition, SP can be committed from a single position even if there are no overlapping securities.
...
If a fund has SS records (both L and S), then for performance attribution to be meaningfulsignificant, the benchmark should also have SS records. CIDX will build Strategy strategy by position from Single single position.
Committing SP from SS
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 instance.
Committing SS from SS
If source entities have L and S records, and if same security is not assigned to multiple nodes in the target dictionary, then the security level build for the CIDX would not fail for SS. This can be committed under SS or SP instance.
Committing SS or SP from 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 fine work for SS if securities are not part of multiple nodes in the target dictionary.
...
The values of the new security types used are stored in the Custom Index Attributes table under the user data column. A possible issue with a custom blend is when one source benchmark contains security level data, and another source benchmark does not. In this case, the build creates a custom benchmark with the securities from only one source benchmark, which can be misleading.
Possible Scenarios for Blended and Floating Weight CIDX Benchmark Types
Use single position and build single position is the default legacy option. There is a limitation of build failing if the security is part of multiple nodes in the target dictionary.
...
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.
Possible
...
Scenarios for Floating Aggregate CIDX Benchmark Type
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 alphabetical order of source Entity Id’s , the security commit process would not fail.
...