Is it possible to apply a time varying “Factor Exposure” when factor exposure constraint is added?

[GilthasLIU]

By reading the document, I found the B matrix/vector, i.e., the “Factor Exposure Matrix”, seemed to be fixed, if the factor exposure constraint would be applied.

But if I’d like to rebalance the portfolio day by day, it is likely that some of the Factor Exposure Matrices would be time varying as well, e.g., the momentum factor would change by nature. So I don’t know if it is possible to allow the B matrix to be time varying, more specifically, a matrix with row number equal to the row number of the return matrix.

And by the way, I don’t quite understand the necessity of the “Training Period”. What parameters do we need to estimate? Or from another perspective, if all the moments of the return series required in the objective/constrains are given, could I bypass the training period when reblancing the portfolio?

Thanks

[braverock]

The current factor_exposure_constraint accepts a fixed B matrix. Time-varying B is not currently supported directly.

Workaround: You can implement time-varying factor exposure via a custom momentFUN or by running optimize.portfolio inside a loop over rebalancing periods, updating the B matrix each time (instead of using optimize.portfolio.rebalancing). Example:

results <- lapply(rebalance_dates, function(d) {
  R_window <- R[paste0(/, d)]  # trailing window
  B_today  <- get_B_matrix(d)    # your time-varying B
  exp_constr <- factor_exposure_constraint(assets, B=B_today, lower=lower, upper=upper)
  optimize.portfolio(R=R_window, portfolio=pspec, constraints=list(exp_constr, ...), ...)
})

Regarding training_period: It controls how much historical return data is used to estimate moments (mean, covariance). If you supply moments directly via a custom momentFUN that ignores R entirely, you can effectively bypass it.

Time-varying factor exposure as a first-class feature would require a significant API change to pass a B-matrix time series to optimize.portfolio.rebalancing. This is a legitimate feature request (not a bug) but is non-trivial to implement. Leaving open as an enhancement for future consideration.