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:
Editing Entity – Build Security Level Options
...
The build security level options (Perf_Summ_Type - “S”) 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.
Use Single position instance and
Build Single Position (Legacy S)
Build Position by Strategy and Dictionary classification (SP).
Build Position by strategy (SS).
Use Position by Strategy and
Build Position by strategy and Dictionary classification (SP).
Build Position by Strategy (SS).
Use SP and Build SS or SP
Committing SP from S
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 can be 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.
...
The various commit scenarios are summarized in the table below. 
...
1 Commit would succeed only if same security is not assigned to more than one node.
...
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 the build failing if the security is part of multiple nodes in the target dictionary.
...
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 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. The system assigns the strategy detail ID accordingly and performs the CIDX build process with SP/SS. The SP 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 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.
...
Possible Scenarios for Floating Aggregate CIDX Benchmark Type
Use Single 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 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 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 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.
If the same security is part of multiple nodes in the target dictionary on the same day, then the SS will not fail. It will aggregate that security if Long only or showing separately if they are Long and Short as they get the strategy detail assigned based on the weights. and assign it to the node according to the alphabetical sorting of the source entities of the entity Entity ID.
In floating aggregate all securities are grouped by security alias. Because S does not have a strategy detail all securities gets grouped under the first available strategy. The ideal configuration would be to build SP for strategies.
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 / under which the source index is attached. That 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 different strategies (Strategy Detail ID) then the SS build option will show the securities under the respective node.
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 Currency Conversion
...