Load Index Data

Owned by Tom Fahey (Unlicensed)
Last updated: Oct 18, 2023 by Pamela Totas (Deactivated)
6 min read

There are several approaches you can use to load index data for use with Eagle Performance. The pros and cons to consider before selecting your approach are described below.

After you select the approach that is best for your organization's needs, you can use Eagle's generic interfaces to load index data. For information about standardized index data integration provided by market data providers such as RIMES, see  Performance Toolkit Implementation.

Index Loading Approach Descriptions

You can consider using one of the following approaches for loading index data. The approaches vary in the amount of data you need to load and maintain. The four approaches include:

  1. Load Index Holdings (Recommended). Treat index as portfolio. Load index constituent holdings into the positions tables. Run performance calculations to populate performance tables. Load the official Index Total return (optionally, sector weights and returns) directly into Performance tables, where you can use them to validate security rollups.

  2. Load Total/Sector/Security. Load index security performance directly into performance tables. Also load Index Total-level return and Sector performance.

  3. Load Total/Sector. Load index Total level Return and Sector level performance data directly into performance tables

  4. Load Total. Load index Total level Return directly into performance tables

  5. Load Total/Sector/Security/Constituent Holdings. Load index security performance directly into performance tables. Also load Index Total level return and Sector performance. Also load index constituent holdings to positions tables.

A description of each approach providing benefits and considerations follows. A chart that compares the approaches on a number of criteria follows.

Understand the Index Loading Approach Diagrams

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.

Approach 1: Load Index Holdings (Recommended)

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.

Approach 2: Load Total/Sector/Security

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.

Approach 3: Load Total/Sector

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.

Approach 4: Load Total

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.

Approach 5: Load Total/Sector/Security/Constituent Holdings

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.

Compare Index Loading Approaches

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).