backtestStrategy

Create backtestStrategy object to define portfolio allocation strategy

Description

Create a backtestStrategy object which defines a portfolio allocation strategy.

Use this workflow to develop and run a backtest:

1. Define the strategy logic using a backtestStrategy object to specify how the strategy rebalances a portfolio of assets.

2. Use backtestEngine to create a backtestEngine object that specifies the parameters of the backtest.

3. Use runBacktest to run the backtest against historical asset price data and, optionally, trading signal data.

4. Use equityCurve to plot the equity curves of each strategy.

5. Use summary to summarize the backtest results in a table format.

For more detailed information on this workflow, see Backtest Investment Strategies Using Financial Toolbox™.

Creation

Syntax

strategy = backtestStrategy(name,rebalanceFcn)

strategy = backtestStrategy(___,Name,Value)

Description

strategy = backtestStrategy(name,rebalanceFcn) creates a backtestStrategy object.

strategy = backtestStrategy(___,Name,Value) sets properties using name-value pair arguments and any of the arguments in the previous syntax. You can specify multiple name-value pair arguments. For example, strat = backtestStrategy('MyStrategy',@myRebalFcn,'TransactionCost',0.005,'LookbackWindow',20).

Input Arguments

name — Strategy name

string

Strategy name, specified as a string.

Data Types: string

rebalanceFcn — Rebalance function

function handle

Rebalance function, specified as a function handle. A function handle computes new portfolio weights during the backtest. The rebalanceFcn argument implements the core logic of the trading strategy and must have one of the following signatures:

• new_weights = rebalanceFcn(weights,assetPrices)

• new_weights = rebalanceFcn(weights,assetPrices,signalData)

The rebalance function is called by the backtestEngine object each time the strategy must be rebalanced. The backtestEngine object calls the rebalance function with the following arguments:

• weights — The current portfolio weights before rebalancing, specified as decimal percentages.

• assetPrices — A timetable containing a rolling window of adjusted asset prices.

• signalData — A timetable containing a rolling window of signal data.

  If you provide signal data to the backtestEngine object, then the engine object passes it to the strategy rebalance function using the three input argument syntax. If do not provide signal data the backtestEngine object, then the engine object calls the rebalance function with the two input argument syntax.

The rebalance function must return a single output argument for new_weights which is a vector of asset weights specified as decimal percentages.

• If the new_weights sum to 1, then the portfolio is fully invested.

• If the new_weights sum to less than 1, then the portfolio will has the remainder in cash, earning the RiskFreeRate specified in the backtestEngine object.

• If the new_weights sum to more than 1, then there is a negative cash position (margin) and the cash borrowed accrues interest at the cash borrowing rate specified in the CashBorrowRate property of the backtestEngine object.

For more information on developing a rebalanceFcn function handle, see Backtest Investment Strategies Using Financial Toolbox™.

Data Types: function_handle

Name-Value Arguments

Specify optional pairs of arguments as Name1=Value1,...,NameN=ValueN, where Name is the argument name and Value is the corresponding value. Name-value arguments must appear after other arguments, but the order of the pairs does not matter.

Before R2021a, use commas to separate each name and value, and enclose Name in quotes.

Example: strat = backtestStrategy('MyStrategy',@myRebalFcn,'TransactionCost',0.005,'LookbackWindow',20)

RebalanceFrequency — Rebalance frequency during backtest

1 (default) | integer | duration object | calendarDuration object | vector of datetime objects

Rebalance frequency during the backtest, specified as the comma-separated pair consisting of 'RebalanceFrequency' and a scalar integer, duration orcalendarDuration object, or a vector of datetime objects.

The RebalanceFrequency specifies the schedule of dates where the strategy will rebalance its portfolio. The default is 1, meaning the strategy rebalances with each time step.

For more information, see Defining Schedules for Backtest Strategies.

Data Types: double | object | datetime

TransactionCosts — Transaction costs for trades

0 (not computed) (default) | numeric | vector | function handle

Transaction costs for trades, specified as the comma-separated pair consisting of 'TransactionCosts' and a scalar numeric, vector, or function handle. You can specify transaction costs in three ways:

• rate — A scalar decimal percentage charge to both purchases and sales of assets. For example ,if you set TransactionCosts to 0.001, then each transaction (buys and sells) would pay 0.1% in transaction fees.

• [buyRate, sellRate] — A 1-by-2 vector of decimal percentage rates that specifies separate rates for buying and selling of assets.

• computeTransactionCostsFcn — A function handle to compute customized transaction fees. If you specify a function handle, the backtestEngine object calls the TransactionCosts function to compute the fees for each rebalance. The user-defined function handle must have the following signature:

  [buyCosts,sellCosts] = computeCostsFcn(deltaPositions)

  The user-defined function handle takes a single input argument deltaPositions, which is a vector of changes in asset positions for all assets (in currency units) as a result of a rebalance. Positive elements in the deltaPositions vector indicate purchases while negative entries represent sales. The user-defined function handle must return two output arguments buyCosts and sellCosts, which contain the total costs (in currency) for the entire rebalance for each type of transaction.

Data Types: double | function_handle

LookbackWindow — Lookback window

[0 Inf] (default) | 1-by-2 vector using integers | duration object | calendarDuration object

Lookback window, specified as the comma-separated pair consisting of 'LookbackWindow' and a 1-by-2 vector of integers, a duration orcalendarDurationobject.

When using a 1-by-2 vector with integers that defines the minimum and maximum size of the rolling window of data (asset prices and signal data) that you provide to the rebalanceFcn argument, you specify these limits in terms of the number of time steps. When specified as integers, the lookback window is defined in terms of rows of data from the asset (pricesTT) and signal (signalTT) timetables used in the backtest. The lookback minimum sets the minimum number of rows of asset price data that must be available to the rebalance function before a strategy rebalance can occur. The lookback maximum sets the maximum size for the rolling window of price data that is passed to the rebalance function.

For example, if the backtestEngine object is provided with daily price data, then LookbackWindow specifies the size bounds of the rolling window in days. The default is [0 Inf], meaning that all available past data is given to the rebalance function. If you specify a non-zero minimum, then the software does not call rebalanceFcn until enough time steps process to meet the minimum size.

If you specify LookbackWindow as a single scalar value, then the value is both the minimum and maximum of the LookbackWindow (that is, a fixed-sized window).

If using a duration or calendarDuration object, the lookback window minimum and maximum are defined in terms of timespans relative to the time at a rebalance. For example if the lookback minimum was set to five days (that is, days(5)), the rebalance will only occur if the backtest start time is at least five days prior to the rebalance time. Similarly, if the lookback maximum was set to six months (that is, calmonths(6)), the lookback window would contain only data that occurred at six months prior to the rebalance time or later.

Note

Alternatively, the LookbackWindow can be set to a single scalar value indicating that the rolling window should be exactly that size (either in terms of rows or a time duration). The minimum and maximum size will both be set to the provided value.

Data Types: double | object

InitialWeights — Initial portfolio weights

[ ] (default) | vector

Initial portfolio weights, specified as the comma-separated pair consisting of 'InitialWeights' and a vector. The InitialWeights vector sets the portfolio weights before the backtestEngine object begins the backtest. The size of the initial weights vector must match the number of assets used in the backtest.

Alternatively, you can set the InitialWeights name-value pair argument to empty ([ ]) to indicate the strategy will begin with no investments and in a 100% cash position. The default for InitialWeights is empty ([ ]).

Data Types: double

ManagementFee — Management fee charged as an annualized percent of the total portfolio value

0 (default) | decimal

Management fee charged as an annualized percent of the total portfolio value, specified as the comma-separated pair consisting of 'ManagementFee' and a numeric scalar. The management fee is the annualized fee rate paid to cover the costs of managing a strategy's portfolio. The management fee is charged based on the strategy portfolio balance at the start of each date specified by the ManagementFeeSchedule. The default is 0, meaning no management fee is paid.

For more information, see Management Fees.

Data Types: double

ManagementFeeSchedule — Management fee schedule

calyears(1) (default) | integer | vector of datetimes | duration object | calendarDuration object

Management fee schedule, specified as the comma-separated pair consisting of 'ManagementFeeSchedule' and a numeric scalar, a duration or calendarDuration object, or alternatively, as a vector of datetimes.

The ManagementFeeSchedule specifies the schedule of dates where the management fee is charged (if a ManagementFee is defined). The default is calyears(1), meaning the management fee is charged annually.

For more information, see Defining Schedules for Backtest Strategies.

Data Types: double | datetime | object

PerformanceFee — Performance fee charged as an absolute percent of the total portfolio growth

0 (default) | decimal

Performance fee charged as a percent of the total portfolio growth, specified as the comma-separated pair consisting of 'PerformanceFee' and a numeric scalar. The performance fee, sometimes called an incentive fee, is a fee paid to reward a fund manager based on performance of the fund. The fee is paid periodically based on the schedule specified by the PerformanceFeeSchedule. The default is 0, meaning no performance fee is paid.

For more information, see Performance Fees.

Data Types: double

PerformanceHurdle — Annualized hurdle rate or column in assets or signals to act as hurdle asset

0 (default) | decimal | string

Annualized hurdle rate or column in assetPrices or signalData to act as hurdle asset, specified as the comma-separated pair consisting of 'PerformanceHurdle' and a numeric scalar or a string. The PerformanceHurdle sets a minimum level of performance that a strategy must achieve before the performance fee is paid.

• If specified as a numeric scalar, the hurdle represents an annualized growth rate, for example 0.05 indicates a 5% growth rate. In this case, the performance fee is only paid if, on a performance fee date, the strategy portfolio value is greater than the high-water mark and the portfolio has produced a return greater than 5% annualized since the start of the backtest. The fee is paid only on the growth in excess of both the hurdle rate and the previous high-water mark.

• If specified as a string, the hurdle must match a column in either the assetPrices or signalData timetables of the backtest and it indicates a hurdle asset. In this case, the performance fee is paid only if the portfolio value is greater than the high-water mark and the portfolio has produced a return greater than the hurdle asset return since the start of the backtest. The performance fee is charged only on the portfolio growth in excess of both the hurdle asset growth and the previous high-water mark.

For more information, see Performance Hurdle.

Data Types: double | string

PerformanceFeeSchedule — Performance fee schedule

calyears(1) (default) | integer | vector of datetimes | duration object | calendarDuration object

Performance fee schedule, specified as the comma-separated pair consisting of 'PerformanceFeeSchedule' and a numeric scalar, a duration or calendarDuration object, or alternatively as a vector of datetimes.

PerformanceFeeSchedule specifies the schedule of dates where the performance fee is charged (if PerformanceFee is defined). The default is calyears(1), meaning the performance fee is charged annually.

For more information, see Defining Schedules for Backtest Strategies.

Data Types: double | datetime | object

Properties

Name — Strategy name

string

Strategy name, specified as a string.

Data Types: string

RebalanceFcn — Rebalance function

function handle

Rebalance function, specified as a function handle.

Data Types: function_handle

RebalanceFrequency — Rebalance frequency during backtest

1 (default) | numeric | duration object | calendarDuration object | vector of datetimes

Rebalance frequency during the backtest, specified as a scalar numeric, duration or calendarDuration object, or vector of datetimes.

Data Types: double | object | datetime

TransactionCosts — Transaction costs

0 (default) | numeric | vector | function handle

Transaction costs, specified as a scalar numeric, vector, or function handle.

Data Types: double | function_handle

LookbackWindow — Lookback window

[0 Inf] (default) | numeric | vector

Lookback window, specified as a scalar numeric or vector.

Data Types: double

InitialWeights — Initial weights

[ ] (default) | vector

Initial weights, specified as a vector.

Data Types: double

ManagementFee — Management fee charged as an annualized percent of the total portfolio value

0 (default) | decimal

Management fee charged as an annualized percent of the total portfolio value, specified as a numeric scalar.

Data Types: double

ManagementFeeSchedule — Management fee schedule

calyears(1) (default) | integer | vector of datetimes | duration object | calendarDuration object

Management fee schedule, specified as scalar numeric, a vector of datetimes, or a duration or calendarDuration object.

Data Types: double | datetime | object

PerformanceFee — Performance fee charged as an absolute percent of the total portfolio growth

0 (default) | decimal

Performance fee charged as an absolute percent of the total portfolio growth, specified as a numeric scalar.

Data Types: double

PerformanceHurdle — Annualized hurdle rate or column in assets or signals to act as hurdle asset

0 (default) | decimal | string

Annualized hurdle rate or column in assetPrices or signalData to act as hurdle asset, specified as a numeric scalar or a string in either assetPrices or signalData as a hurdle asset.

Data Types: double | string

PerformanceFeeSchedule — Performance fee schedule

calyears(1) (default) | decimal | vector of datetimes | duration object | calendarDuration object

Performance fee schedule, specified as a scalar numeric, vector of datetimes, or a duration or calendarDuration object.

Data Types: datetime | object

Examples

Create Backtesting Strategies

Define a backtest strategy by using a backtestStrategy object. backtestStrategy objects contain properties specific to a trading strategy, such as the rebalance frequency, transaction costs, and a rebalance function. The rebalance function implements the core logic of the strategy and is used by the backtesting engine during the backtest to allow the strategy to change its asset allocation and to make trades. In this example, to illustrate how to create and use backtest strategies in MATLAB®, you prepare two simple strategies for backtesting:

1. An equal weighted strategy

2. A strategy that attempts to "chase returns"

The strategy logic for these two strategies is defined in the rebalance functions.

Set Strategy Properties

A backtestStrategy object has several properties that you set using parameters for the backtestStrategy function.

Initial Weights

The InitialWeights property contains the asset allocation weights at the start of the backtest. The default value for InitialWeights is empty ([]), which indicates that the strategy begins the backtest uninvested, meaning that 100% of the capital is in cash earning the risk-free rate.

Set the InitialWeights to a specific asset allocation. The size of the initial weights vector must match the number of assets in the backtest.

% Initialize the strategies with 30 weights, since the backtest
% data comes from a year of the 30 DJIA stocks.
numAssets = 30;

% Give the initial weights for both strategies equal weighting. Weights
% must sum to 1 to be fully invested.
initialWeights = ones(1,numAssets);
initialWeights = initialWeights / sum(initialWeights);

Transaction Costs

The TransactionCosts property allows you to set the fees that the strategy pays for trading assets. Transaction costs are paid as a percentage of the total change in position for each asset. Specify costs in decimal percentages. For example, if TransactionCosts is set to 1% (0.01) and the strategy buys $100 worth of a stock, then the transaction costs incurred are $1.

Transaction costs are set using a 1-by-2 vector that sets separate fee rates for purchases and sales of assets. In this example, both strategies pay the same transaction costs — 25 basis points for asset purchases and 50 basis points for sales.

% Define the Transaction costs as [buyCosts sellCost] and specify the costs
% as decimal percentages.
tradingCosts = [0.0025 0.005];

You can also set the TransactionCosts property to a function handle if you need to implement arbitrarily complex transaction cost structures. For more information on creating transaction cost functions, see backtestStrategy.

Rebalance Frequency

The RebalanceFrequency property determines how often the backtesting engine rebalances and reallocates the portfolio of a strategy using the rebalance function. Set the RebalanceFrequency in terms of time steps in the backtest. For example, if the backtesting engine is testing a strategy with a set of daily price data, then set the rebalance function in days. Essentially, RebalanceFrequency represents the number of rows of price data to process between each call to the strategy rebalance function.

% Both strategies rebalance every 4 weeks (20 days).
rebalFreq = 20;

Lookback Window

Each time the backtesting engine calls a strategy rebalance function, a window of asset price data (and possibly signal data) is passed to the rebalance function. The rebalance function can then make trading and allocation decisions based on a rolling window of market data. The LookbackWindow property sets the size of these rolling windows. Set the window in terms of time steps. The window determines the number of rows of data from the asset price timetable that are passed to the rebalance function.

The LookbackWindow property can be set in two ways. For a fixed-sized rolling window of data (for example, "50 days of price history"), the LookbackWindow property is set to a single scalar value (N = 50). The software then calls the rebalance function with a price timetable containing exactly N rows of rolling price data.

Alternatively, you can define the LookbackWindow property by using a 1-by-2 vector [min max] that specifies the minimum and maximum size for an expanding window of data. In this way, you can set flexible window sizes. For example:

• [10 Inf] — At least 10 rows of data

• [0 50] — No more than 50 rows of data

• [0 Inf] — All available data (that is, no minimum, no maximum); this is the default value

• [20 20] — Exactly 20 rows of data; this is equivalent to setting LookbackWindow to the scalar value 20

The software does not call the rebalance function if the data is insufficient to create a valid rolling window, regardless of the value of the RebalanceFrequency property.

If the strategy does not require any price or signal data history, then you can indicate that the rebalance function requires no data by setting the LookbackWindow property to 0.

% The equal weight strategy does not require any price history data.
ewLookback = 0;

% The "chase returns" strategy bases its decisions on the trailing
% 10-day asset returns. The lookback window is set to 11 since computing 10 days 
% of returns requires the close price from day 0.
chaseLookback = 11;

Rebalance Function

The rebalance function (rebalanceFcn) is the user-authored function that contains the logic of the strategy. The backtesting engine calls the strategy rebalance function with a fixed set of parameters and expects it to return a vector of asset weights representing the new, desired portfolio allocation after a rebalance. For more information, see the rebalance functions.

Create Strategies

Using the prepared strategy properties, you can create the two strategy objects.

% Create the equal weighted strategy. The rebalance function @equalWeights
% is defined in the Rebalance Functions section at the end of this example.
equalWeightStrategy = backtestStrategy("EqualWeight",@equalWeight, ...
    'RebalanceFrequency',rebalFreq, ...
    'TransactionCosts',tradingCosts, ...
    'LookbackWindow',ewLookback, ...
    'InitialWeights',initialWeights)

equalWeightStrategy = 
  backtestStrategy with properties:

                      Name: "EqualWeight"
              RebalanceFcn: @equalWeight
        RebalanceFrequency: 20
          TransactionCosts: [0.0025 0.0050]
            LookbackWindow: 0
            InitialWeights: [0.0333 0.0333 0.0333 0.0333 0.0333 0.0333 ... ]
             ManagementFee: 0
     ManagementFeeSchedule: 1y
            PerformanceFee: 0
    PerformanceFeeSchedule: 1y
         PerformanceHurdle: 0

% Create the "chase returns" strategy.  The rebalance function
% @chaseReturns is defined in the Rebalance Functions section at the end of this example.
chaseReturnsStrategy = backtestStrategy("ChaseReturns",@chaseReturns, ...
    'RebalanceFrequency',rebalFreq, ...
    'TransactionCosts',tradingCosts, ...
    'LookbackWindow',chaseLookback, ...
    'InitialWeights',initialWeights)

chaseReturnsStrategy = 
  backtestStrategy with properties:

                      Name: "ChaseReturns"
              RebalanceFcn: @chaseReturns
        RebalanceFrequency: 20
          TransactionCosts: [0.0025 0.0050]
            LookbackWindow: 11
            InitialWeights: [0.0333 0.0333 0.0333 0.0333 0.0333 0.0333 ... ]
             ManagementFee: 0
     ManagementFeeSchedule: 1y
            PerformanceFee: 0
    PerformanceFeeSchedule: 1y
         PerformanceHurdle: 0

Set Up Backtesting Engine

To backtest the two strategies, use the backtestEngine object. The backtesting engine sets parameters of the backtest that apply to all strategies, such as the risk-free rate and initial portfolio value. For more information, see backtestEngine.

% Create an array of strategies for the backtestEngine.
strategies = [equalWeightStrategy chaseReturnsStrategy];

% Create backtesting engine to test both strategies.
backtester = backtestEngine(strategies);

Rebalance Functions

Strategy rebalance functions defined using the rebalanceFcn argument for backtestStrategy must adhere to a fixed API that the backtest engine expects when interacting with each strategy. Rebalance functions must implement one of the following two syntaxes:

function new_weights = exampleRebalanceFcn(current_weights,assetPriceTimeTable)

function new_weights = exampleRebalanceFcn(current_weights,assetPriceTimeTable,signalDataTimeTable)

All rebalance functions take as their first input argument the current allocation weights of the portfolio. current_weights represents the asset allocation just before the rebalance occurs. During a rebalance, you can use current_weights in a variety of ways. For example, you can use current_weights to determine how far the portfolio allocation has drifted from the target allocation or to size trades during the rebalance to limit turnover.

The second and third arguments of the rebalance function syntax are the rolling windows of asset prices and optional signal data. The two tables contain the trailing N rows of the asset and signal timetables that are passed to the runBacktest function, where N is set using the LookbackWindow property of each strategy.

If optional signal data is provided to the runBacktest function, then the backtest engine passes the rolling window of signal data to each strategy that supports it.

The equalWeight strategy simply invests equally across all assets.

function new_weights = equalWeight(current_weights,assetPrices) %#ok<INUSD> 

% Invest equally across all assets.
num_assets = numel(current_weights);
new_weights = ones(1,num_assets) / num_assets;

end

The chaseReturns strategy invests only in the top X stocks based on their rolling returns in the lookback window. This naive strategy is used simply as an illustrative example.

function new_weights = chaseReturns(current_weights,assetPrices) 

% Set number of stocks to invest in.
numStocks = 15;

% Compute rolling returns from lookback window.
rollingReturns = assetPrices{end,:} ./ assetPrices{1,:};

% Select the X best performing stocks over the lookback window
[~,idx] = sort(rollingReturns,'descend');
bestStocksIndex = idx(1:numStocks);

% Initialize new weights to all zeros.
new_weights = zeros(size(current_weights));

% Invest equally across the top performing stocks.
new_weights(bestStocksIndex) = 1;
new_weights = new_weights / sum(new_weights);

end

More About

Defining Schedules for Backtest Strategies

A backtesting schedule is a set of dates defining when specific events will occur.

The backtestStrategy object uses schedules in several of ways, including setting the rebalance frequency (RebalanceFrequency), the performance fee (PerformanceFeeSchedule), and the management fee (ManagementFeeSchedule) schedules. Schedules are specified with a syntax that supports a variety of data types, which include numeric scalars, a vector of datetimes, and duration or calendarDuration objects. The resulting schedules for the different data types are:

• Numeric — If a schedule is defined using a numeric scalar, it refers to the number of rows (of the assetPrices timetable) between each event in the schedule, starting from the backtest start date. For example, if a schedule is set to 10, then the schedule event (a rebalance date or fee payment date) occurs on every 10th row of the prices timetable while the backtest runs.

• duration or calendarDuration — If specified as a duration or calendarDuration object, the schedule specifies a duration of time between each event (rebalance date or fee payment date). The schedule is calculated starting at the backtest start date and then schedule dates are added after each step of the specified duration.

• Vector of datetimes — If the numeric or duration syntaxes are not appropriate, then you can explicitly specify schedules using a vector of datetimes.

Note

For both the duration and datetime syntaxes, if a resulting schedule date is not found in the backtest data set (the assetPrices timetable), the backtestEngine either adjusts the date to the nearest valid date or else issues an error. This behavior is controlled by the DateAdjustment property of the backtestEngine object. By default, dates are adjusted to the nearest previous date. For example, if a schedule date falls on a Saturday, and is not found in the backtest data set, then the date is adjusted to the previous Friday. Alternatively, the backtestEngine DateAdjustment property allows you to adjust dates to the next valid date, or to issue an error if a date is not found by requiring exact dates.

Management Fees

The management fee is the annualized rate charged on the assets under management of the strategy to pay for the fund's management costs.

The fee is charged on each date specified by the ManagementFeeSchedule name-value argument. For more information, see Defining Schedules for Backtest Strategies.

The management fee is forward looking, meaning that a fee paid on a given date covers the management of the strategy from that date to the next management fee date. For some syntaxes of theManagementFeeSchedule, the resulting schedule does not begin and end precisely on the backtest start and end dates. In these cases, the backtest engine adds default dates to the start and end of the schedule to ensure that the entire backtest is covered by management fees. For example:

• If ManagementFeeSchedule is specified as a vector of datetimes, and the backtest start date is not included in the vector, then the start date is added to the fee schedule.

  

• If ManagementFeeSchedule is specified as a numeric scalar or a vector of datetimes, and the final specified fee date occurs before the backtest end date, then the backtest end date is added to the fee schedule.

  

• If ManagementFeeSchedule is specified as a duration or calendarDuration object, and the backtest end date is not included in the generated schedule, then a final fee date is added to the end by adding the duration object to the (previous) final fee date. This adjustment can produce a final fee date that is beyond the end of the backtest, but it results in more realistic fees paid at the final payment date.

  

For more information on where the resulting management fees are reported, see the backtestEngine object read-only property Fees.

Performance Fees

A performance fee, or incentive fee, is a periodic payment that is paid by fund investors based on the fund's performance.

The performance fee can have a variety of structures, but it often is calculated as a percentage of a fund's increase in NAV over some tracked high-water mark. This calculation ensures the fee is paid only when the investment manager produces positive results. Performance fees in hedge funds are sometimes set at 20%, meaning if the fund NAV goes from $1M to $1.2M, a fee of $40k would be charged (20% of the $200k growth).

During the backtest, the backtest engine tracks a high-water mark. The high-water mark starts at the portfolio initial value. At each performance fee date, if the portfolio value is greater than the previous high-water mark, then the high-water mark is updated to the new portfolio value and the performance fee is paid on the growth of the portfolio. The portfolio growth is the difference between the new high-water mark and the previous one. If, on a performance fee date, the portfolio value is less than the previous high-water mark, then no fee is paid and the high-water mark is not updated.

The high-water mark is typically updated at each performance fee date and does not track maximum portfolio values between dates, as illustrated:

For more information on where the resulting performance fees are reported, see the backtestEngine object read-only property Fees.

Performance Hurdle

A hurdle is an optional feature of a performance fee.

A hurdle sets a minimum performance threshold that a fund must beat before the performance fee is charged. Hurdles can be fixed rates of return, a hurdle rate, such as 5%. For example, if the fund NAV goes from $1M to $1.2M, the performance fee is charged only on the performance beyond 5%. A 5% hurdle rate on $1M sets the target hurdle value at $1.05M. The $1.2M portfolio is $150k over the hurdle value. The performance fee is charged only on that $150k, so 20% of $150k is a $30k performance fee.

The following figure illustrates a 5% hurdle rate.

You can also specify a performance hurdle as a benchmark asset or index. In this case, the performance fee is paid only on the fund performance in excess of the hurdle instrument. For example, assume that the fund NAV goes from $1M to $1.2M and you have specified the S&P500 as your hurdle. If the S&P500 index returns 25% over the same period, then no performance fee is paid because the fund did not produce returns in excess of the hurdle instrument. If the fund value is greater than the hurdle, but still less than the previous high-water mark, again, no performance fee is paid.

At each performance fee date, the fund charges the performance fee on the difference between the current fund value and the maximum of the high-water mark and the hurdle value. The high-water mark is updated only if a performance fee is paid.

For more information on where the resulting performance fees are reported, see the backtestEngine object read-only property Fees.

Version History

Introduced in R2020b

R2022b: Management and performance fees

The backtestStrategy object supports name-value arguments for ManagementFee, ManagementFeeSchedule, PerformanceFee, PerformanceHurdle, and PerformanceFeeSchedule.

R2022a: Include NaN values in asset price data

The backtestStrategy object supports NaNs in the assetPrices timetable and NaNs and <missing> in the signalData timetable.