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.
...
- Create a Blended Weighted Benchmark
- Create a Static Floating Weight Benchmark
- Create a Floating Aggregate Benchmark
- Create a Currency Conversion Benchmark
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”) have been modified to include the existing now include Perf_summ_type S and added with the newly introduced Perf_Summ Types – SS and SP. The Custom Index Module can consume and commit commit security type returns like SS and SP for the following options: Blended Weighted, Floating Weight, Floating Aggregate and Currency Conversion CIDX benchmark types.
...
CIDX types like blended, floating weight, and floating aggregate require security returns from multiple source entities. In the case of With floating weight and blended benchmarks, if there were are overlapping securities across nodes in the target dictionary, the security commit process failed earlier due to inherent limitations in database designfails.
This can be overcome by committing Position by strategy Strategy and dictionary classification Dictionary Classification (SP) records, which involves committing 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.
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 ID in 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.
...