| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
The figures that accompany each approach identify the type of data you can load automatically (using Eagle's generic interfaces, such as message streams or uploaders), along with the types of data you can enter manually (to define custom benchmarks, sub-portfolios, and/or aggregates) when using that approach. It also describes the database table where Eagle stores that data after entry. For example, when you load entity data for an index using a generic stream, the system stores that data in the ENTITY table.
Depending on the approach you select, you can load or manually enter entity data for indexes, custom benchmark data, performance data (at the Total, Total/Rollup, or Total/Rollup/Security levels), entity data for sub-portfolios and aggregates, constituent performance data (security level index holdings), security master (SMF) data (used for security level analyses), and security analytics (used in attribution analysis for fixed income indexes only).
The Load Index Holdings approach shown in the following figure is the only approach that utilizes Eagle's performance calculation (Perf Calc) to calculate index holdings based weights and returns at the same levels used by the Fund. As you look at the following figure, notice how the Perf Calc uses entity data, SMF data, and index holdings data to enhance the performance data loaded at the Total/Rollup level. It updates the dictionary tables that describe the performance model structures used to group data, and updates the performance tables with index holdings based performance data.
The Load Index Holdings approach shown in the following figure uses all the data inputs described above. The other index loading approaches require less data — their corresponding figures identify data/processes/tables not used for each approach in light gray.
| Anchor | ||||
|---|---|---|---|---|
|
With this approach, you treat the index as a portfolio. You:
Load index positions.
Run performance calculations to populate PERFORM tables.
Load the official Index Total return (optionally, sector weights and returns) directly into PERFORM tables, where you can use them to validate security rollups.
The following figure shows a high level view of the index data loaded and how it is stored for this approach.
Business Requirements/Objectives
This approach offers the most robust solution, following the approach most similar to processing an invested portfolio. This is the best option to support Fixed Income Attribution, Positioning Reports, Custom Classifications, Security Analytics, or Building Entity Sub-portfolios/Aggregates. This solution supports all variations of Performance and Performance Attribution reports and Custom Benchmark construction (including both Fixed Income and Equity Attribution).
Benefits
Consistent roll-ups for index and portfolio.
Supports entity sub-portfolio and aggregates.
Includes checks that rollups match official return (optionally, sector weights and returns).
Provides supporting data for reporting and resolving data inconsistencies.
Supports security level custom benchmark construction.
Supports standard and Dynamic performance.
Supports nonstandard classifications.
Considerations
Security level rollups might not match official data.
This approach requires performance calculation processing.
This approach requires purchasing and managing security level data for SMF and positions.
| Anchor | ||||
|---|---|---|---|---|
|
With this approach, you:
Load index security performance directly into PERFORM tables.
Load Index Total level return and Sector performance.
The following figure shows a high level view of the index data loaded and how it is stored for this approach.
Business Requirements/Objectives
This approach omits the performance calculation process and loads only industry-standard data directly into Performance tables. This approach supports most performance reports and custom benchmark builds. Because the position's data is not stored in the holdings tables, it does not support position reports or Entity Builds.
Benefits
Does not require Index performance calculation processing.
Includes checks that rollups match official return (optionally, sector weights and returns).
Provides supporting data for reporting and resolving data inconsistencies.
Supports security level custom benchmark construction.
Supports standard and Dynamic performance.
Considerations
It does not support Entity aggregates and sub-portfolios.
Possible inconsistencies with rollups for invested portfolio.
Index security level rollups might not match official sector data.
It requires purchasing and managing security level data for SMF and performance.
Only supports sectors provided by the index vendor.
| Anchor | ||||
|---|---|---|---|---|
|
Load index Total level Return and Sector level performance data directly into PERFORM tables. The following figure shows a high level view of the index data loaded and how it is stored for this approach.
Business Requirements/Objectives
This approach is appropriate when no security level index data is available or required. It is the simplest approach to support sector-based attribution and performance reports. It supports building custom benchmarks based on sectors.
Benefits
Does not require Index performance calculation processing.
Only requires purchasing and managing sector level data.
Includes checks that Sectors match official weights and returns.
Considerations
It does not support entity aggregates and sub-portfolios.
Possible inconsistencies with rollups for invested portfolio.
Sector rollups might not match official Total level data.
Only supports sectors provided by the index vendor.
Limited support for Custom Benchmark.
Does not support security level attribution or Dynamic performance.
Comments
This approach is identical to the Load Total approach, but additionally provides the sector rollup. It does not require storage of security level data in the PERF_SEC_ROLLUP_RELATION or PERF_SEC_UNIVERSE tables.
| Anchor | ||||
|---|---|---|---|---|
|
Load index Total level Return directly into PERFORM tables. The following figure shows a high level view of the index data loaded and how it is stored for this approach.
Business Requirements/Objectives
This approach is appropriate when no sector level or security level index data is available or required. It is the simplest approach to support performance reports.
Benefits
Does not require Index performance calculation processing.
Does not require purchasing and managing sector level data or security data.
Considerations
It does not support entity aggregates and sub-portfolios.
Does not support performance analysis reports that calculate or report benchmarks data below the total level.
Limited support for Custom Benchmark.
Does not support attribution or Dynamic performance.
Comments
This approach is identical to the Load Total/Sector approach, but lacks the sector rollup. It does not require storage of security level data in the PERF_SEC_ROLLUP_RELATION or PERF_SEC_UNIVERSE tables.
| Anchor | ||||
|---|---|---|---|---|
|
With this approach, you:
Load index security performance directly into PERFORM tables.
Load Index Total level return and Sector performance.
Load index constituent holdings to positions tables.
The following figure shows a high level view of the index data loaded and how it is stored for this approach.
Business Requirements/Objectives
This approach omits the performance calculation process and loads only industry-standard data directly into Performance tables. It also loads index constituent holdings to the positions tables. This approach supports most performance reports and custom benchmark builds. Because the position's data is stored in the holdings tables, it supports position reports and Entity Builds.
Benefits
Does not require Index performance calculation processing.
Includes checks that rollups match official return (optionally, sector weights and returns).
Provides supporting data for reporting and resolving data inconsistencies.
Supports security level custom benchmark construction.
Supports standard and Dynamic performance.
Supports Entity aggregates and sub-portfolios.
Considerations
Possible inconsistencies with rollups for invested portfolio.
Index positions data might not match official index security returns.
Index security level rollups might not match official sector data.
This approach requires purchasing and managing security level data for SMF and performance.
Only supports sectors provided by the index vendor.
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
| Anchor | ||||
|---|---|---|---|---|
|
The following table compares the index loading approaches, based on numerous criteria. A description of each column in the table follows.
Approach. Name of the index loading approach.
Entity. Indicates whether you need to create an Entity record for the index. (Y/N)
Data Sourced/Tables Loaded. Indicates whether you need to load index related data for:
SMF-Port. SMF records for the Portfolio (Y/N)
SMF-BM. SMF records for the Benchmark (Y/N)
Positions. Index positions. (Y/N)
Performance. Performance records (identifies performance model levels at which you load index data)
Performance Calculation Required. Describes whether you need to run performance calculations (Perf Calc) for:
Benchmark. Benchmark type reports
Portfolio. Portfolio type reports.
If so, identifies the performance model levels at which Eagle Performance calculates performance data.
Supported Performance Models. Describes whether the approach supports:
Ind Stnd. Industry-Standard performance models. (Y/N)
Cust. Custom performance models. (Y/N)
Dyn. Dynamic performance models. (Y/N)
For information about Dynamic performance models, see Performance Analysis and Reporting.
Supported Custom Benchmark Creation. Describes whether the approach supports the creation of custom benchmarks at the following levels:
Total. Supports Total level custom benchmarks.
Sect. Supports Total/Sector level custom benchmarks.
Secur. Supports Total/Sector/Security level custom benchmarks.
Cust Sect. Supports custom benchmarks with custom sectors, that is, performance models not supplied by index providers.
Support Pos Rpt & Ent Bld. Support Position reports and Entity Builds. Describes whether the approach supports use of Eagle Position reports and Entity builds. (Y/N).