You can use a Linked type benchmark to:

• Create a Linked Benchmark. A Linked benchmark links different entities, such as indexes or custom indexes, at the Total level over time. The linked index is assigned to be equal to the Total level of only one entity at any given time.

For example, Custom Index 2 is equal to 100 percent of the S&P 500 for 1/31/95 to 1/31/98. Then, from 1/31/98 forward, Custom Index 2 is equal to 100 percent of the Russell 2000.

• Create a Hurdle-Based Benchmark. A Hurdle Based benchmark allows you to build a benchmark with a return specified as a certain number of basis points relative to a source benchmark. You can apply the basis points offset to each observation in the period or you can adjust for compounding.

For example, in year 1, Custom Index 3 is equal to 100 basis points above the S&P 500. In year 2, Custom Index 3 is equal to 125 basis points above the S&P 500.

Calculate Returns for Linked Benchmarks

A linked benchmark has a one to one relationship with its underlying source entity. Note that you can only create a linked benchmark at the Total level.

An example of a linked benchmark is defined in the following table.

Data results in the database for the linked benchmark are in the following table.

Calculate Returns for Hurdle Based Benchmarks

When you create a hurdle based benchmark, the hurdle based benchmark has a one to one relationship with its underlying source entity. You can use an index, a custom benchmark, or another portfolio as the source entity. Because the hurdle based benchmark is a Linked type benchmark, you can only create a hurdle based benchmark at the Total level. In addition, you can:

• Adjust the return by a positive or negative number of basis points (bp) relative to the source entity over a year.
• Use Daily or Monthly frequency to calculate returns for the custom benchmark.
• Change the source entity and number of basis points within an annual period.
• Select a noncompounded or a compounded adjustment methodology.

Calculate the Custom Benchmark during the Entity Build

During the entity build, the system calculates a simple Nth root offset. It applies this offset in different ways, depending on whether or not you adjust for compounding effects.

To calculate the Nth root offset to apply, the system uses the entity's business calendar to find the expected number of business days in the prior year ending on the calculation date. This count is the N in the Nth root. If there is no entity-specific business calendar, the system uses the Eagle PACE business calendar.

For monthly calculations, the N is the number of full months in the past year. It is normally 12.

For daily index calculations, the start of the annual period is calculated by subtracting 1 from the year of the date being built. For daily index calculations on February 29, the start of the annual period is February 28 of the prior year. The business calendar identifies the exact historical dates for which data is expected. For Monthly frequency, this is normally calendar month-ends. Daily frequency reflects weekends and holiday schedules.

The system allows you to change the custom benchmark definition, but the annual result may not match the +bps specified if the time period spans two custom benchmark definitions. This occurs because the new definition applies only from its effective date and does not recalculate prior periods. You can also build two Linked hurdle based benchmarks with static definitions and then create a third Linked benchmark that switches between the two hurdle based benchmarks.

Calculate Hurdle Based Returns without Compounding

If you calculate a hurdle based return without compounding, Eagle Performance applies a simple Nth root offset to each observation in the period. If you link the returns for a year, the system may not create an annual return adjusted by exactly the specified number of bps, due to compounding effects.

The system can calculate the CIDX effective dates in any order. For example, a monthly index with 100bps adjustment has added to the return of the source index for every month in the year.

Calculate Hurdle Based Returns Adjusted for Compounding

If you calculate a hurdle based return adjusted for compounding, Eagle Performance adjusts for compounding effects by calculating a running return for the period that is adjusted by the specified bps, and then backing into the return for the observation date being calculated.

This methodology uses the same approach as the noncompounded method to calculate the Nth root offset to apply. However, the adjustment is not the same for each observation and the system must calculate the observations in order, as it does for floating benchmarks.

In order to adjust for compounding, the entity build accesses the unadjusted (source) returns and adjusted (target) returns for the prior year or back to the entity's last definition change (whichever is more recent). The system takes returns from the stored returns in the PERF_SEC_RETURNS table for each of the specified advanced fields with a CIDX return process type. The system only needs to calculate the return for the current day—no prior returns are adjusted.

Note that the system considers only the most recent definition when calculating for any period.

It must calculate every period from the definition forward in sequence. This is necessary because the current day is adjusted based on the returns of prior days within the annual period (one year or a portion of the year if the last definition is less than a year prior to the effective date for the calculation). The numerator in the equation is the linked unadjusted returns for the year plus the appropriate portion of the yearly bps adjustment (using the appropriate Nth root for each period). The denominator in the equation is the linked adjusted returns for the prior periods in the year. The appropriate portion of adjustment is based on the number of observations in the year (12 for monthly) and the number of periods that have passed for the year.

The adjustment uses only prior performance data for the frequency being calculated. This means a daily calculation requires prior daily returns and a monthly calculation requires prior monthly returns. Neither frequency uses prior data stored under the other frequency.

This solution states each daily return using a running adjustment that can be calculated without knowing future periods and does not restate prior periods. It applies a cumulative 12th root adjustment and backs into each daily return by unlinking the cumulative adjusted return for the prior day. This provides an adjusted daily (or monthly) return series that links to the required adjustment over the period. It calculates a rolling adjustment that works for any annual period.