...
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.
...
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.
...