Build Custom Benchmarks at the Security Level
- Pamela Totas (Deactivated)
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 custom benchmark builder can build both segment and security level returns for a custom benchmark. The segment and security levels created for each entity build are dependent upon the source data. The entity build uses whatever source data is available in the database for the indicated source entities to create the blend.
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.
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. With this enhancement, the security would be committed at multiple nodes under ‘SP’ instance if the option is chosen on user interface.
Committing SS from S
If a fund has SS records (both L and S), then for performance attribution to be significant, the benchmark should also have SS records. CIDX will build strategy by position from 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.
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.
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 for SS if securities are not part of multiple nodes in the target dictionary.
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.
2Committing SS from SP is supported for Floating weight and Blended benchmark only.
The Target entity is built and supported only for the same type of input underlying source entities. For example, if Source 1 has S, and Source 2 has SS the build will fail.
CIDX types with single source entity like currency conversion have the option of which security type returns to be chosen for source and target. Here S source can create S. SS can create SS, and SP can create SP.
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.
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 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 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 benchmarks, 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.
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 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 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
You can build the new security type options from the drop down. You can use and build the same security type option such as use strategy by position and build strategy by position, use strategy by position and dictionary classification, and build position by strategy and dictionary classification.