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 for entity Index Attributes of Blended Weighted, Floating Weight, Floating Aggregate, and Currency Conversion custom benchmarks.
Editing Entity – Build Security Level Option
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”) have been modified to include the existing Perf_summ_type S and added with the newly introduced Perf_Summ Types – SS and SP. The Custom Index Module can consume and commit 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. In the case of floating weight and blended benchmarks, if there were overlapping securities across nodes in the target dictionary, the security commit process failed earlier due to inherent limitations in database design.
This can be overcome by committing Position by strategy and dictionary classification (SP) records, which involves committing same security returns under multiple nodes in the target dictionary. In addition, SP can be committed from single position even if there are no overlapping securities.
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 Entity Id order of source 1 and source 2 (the security commit process would not fail). With this enhancement, the security will be committed at multiple nodes under ‘SP’ instance, if the option is chosen on UI.
Committing SS from S
If a fund has SS records (both L and S), then for performance attribution to be meaningful, 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 source entities, then the target could be either SS or SP. If 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 security type for source entities, then the target could be either SS or SP. The CIDX build for the security would work fine 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 will be 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.
For CIDX types with single source entity like Currency Conversion (Exclusion and constrained – to be made available in future version), have the option of which security type returns to be picked 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 and built is 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.
Use Single position and build single position is the default legacy option and will continue to work the same way as before with the limitation of 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 long strategy and the negative weights as short strategy and assigns the strategy detail ID accordingly to it and does 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 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 / under which the source index is attached. The source index will be part of that strategy. Assume we have two strategies Core and Tactical, then 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.
Add Comment