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 sections that follow provide detailed definitions and methodologies of the types of custom benchmarks and the data required to build each of them.This This section describes the Build Security Level feature available for entity Custom Index Attributes of Blended Weighted, Floating Weight, Floating Aggregate, and Currency conversion 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. Both the 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 will now be able to can consume and commit the newly introduced commit security type returns like SS and SP for the following options: Blended Weighted, Floating Weight, Floating Aggregate and Currency Conversion CIDX benchmark types.
...
Committing SP from S
CIDX types like Blendedblended, Floating floating weight and Floating Aggregate floating aggregate require security returns from multiple source entities.In 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 single position even if there are no overlapping securities although it serves no additional purpose.
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.
...
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 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.
...