Forem: Sergey Kikevich

okama 2.0: New Withdrawal Strategies and a Faster Efficient Frontier

Sergey Kikevich — Tue, 07 Apr 2026 11:42:23 +0000

We have released the “anniversary” version, okama 2.0. This release includes many important changes. The main themes are new advanced portfolio withdrawal strategies and a new portfolio optimization workflow for the Efficient Frontier.

First article and howto for beginners is here.

You can install the library or upgrade to the new version right now:

pip install okama -U

With okama 2.0, we deliberately moved from educational and academic examples toward more practical and realistic use cases. On the one hand, the library now includes new tools that are well suited for building retirement strategies with regular withdrawals.

On the other hand, the logic behind the Efficient Frontier has changed: multi-period optimization with rebalancing is now the default behavior. This more advanced type of optimization is also dramatically faster. You no longer need to leave your computer running and go make tea while the calculations finish. This makes okama much better suited for web applications. Changes on okama.io are coming soon.

Cash Flow and Discounting Strategies

The new withdrawal strategies are built into the existing discounted cash flow analysis architecture in the PortfolioDCF class. The portfolio remains a separate object, while the cash flow strategy is attached through pf.dcf.cashflow_parameters. This design makes it possible to test portfolio structure, rebalancing rules, and withdrawal logic independently.

The simplest investment portfolio can be created in just two lines of code:

import okama as ok

pf = ok.Portfolio()  # by default, this is a portfolio with a single SPY fund

Vanguard Dynamic Spending (VDS) Withdrawal Strategy

Version 1.5.0 introduced a percentage-based withdrawal strategy through the PercentageStrategy class. The new VanguardDynamicSpending (VDS) class develops this idea further: withdrawals are still defined as a fixed percentage of the portfolio balance, but additional constraints are applied.

This is an important distinction. The new strategy does not replace the original percentage-based model. It extends it. The underlying ideas come from Vanguard research.

The key new parameter in VDS is floor_ceiling. It limits how much the withdrawal amount can change relative to the previous year. For example, (-0.025, 0.05) means that the new withdrawal cannot be more than 5% higher and cannot be more than 2.5% lower than the previous year’s withdrawal. This prevents spending from changing too abruptly in response to market moves.

Absolute limits can also be defined with min_max_annual_withdrawals. If adjust_min_max=True, these limits are indexed, for example to inflation. The adjust_floor_ceiling parameter works in a similar way: the previous year’s withdrawal can first be indexed, and only then are the floor and ceiling applied. In effect, VDS combines a percentage link to portfolio size with explicit control over consumption volatility.

Limitations: VDS only works with regular withdrawals, without contributions, and the withdrawal frequency is always annual.

The strategy is created as follows:

vds = ok.VanguardDynamicSpending(
    parent=pf,
    initial_investment=1_000_000,  # starting capital
    percentage=-0.08,  # withdrawal rate
    floor_ceiling=(-0.025, 0.05),  # allowed change in the withdrawal amount
)

pf.dcf.cashflow_parameters = vds

In applied portfolio modeling, VDS is useful when an investor wants spending to remain linked to portfolio value, but does not want the amount withdrawn to fluctuate too sharply from year to year. For retirement planning, this is much closer to real-world behavior than a pure percentage rule without guardrails.

Cut Withdrawals If Drawdown (CWD) Strategy

This strategy is built on a different philosophy. The withdrawal amount reflects the retiree’s real spending needs rather than the current portfolio value. This approach first appeared in version 1.5.0 through the IndexationStrategy class.

The new strategy allows withdrawals to be reduced during market drawdowns. This is close to what many advisors and academic studies recommend, because a portfolio is often damaged most severely by withdrawals taken during deep declines.

The CutWithdrawalsIfDrawdown (CWD) class defines this behavior through withdrawal limits that depend on the depth of the portfolio drawdown.

The crash_threshold_reduction parameter is specified as a list of pairs in the form (drawdown threshold, reduction factor). For example, (0.20, 0.40) means that if the portfolio drawdown exceeds 20%, the current withdrawal is reduced by 40%. And (0.35, 1) means that withdrawals are effectively suspended if the drawdown is deeper than 35%.

This strategy is particularly useful in models where the user wants to preserve a clear baseline spending amount while encoding anti-crisis behavior in advance. It is no longer just “withdraw a fixed inflation-indexed amount,” but rather manage the pace of withdrawals depending on drawdown depth.

Creating a CWD strategy:

cwd = ok.CutWithdrawalsIfDrawdown(
    parent=pf,
    initial_investment=1_000_000,  # starting capital
    frequency="year",  # withdrawal frequency
    amount=-60_000,  # target withdrawal amount in today’s money
    indexation="inflation",  # index withdrawals to inflation
    crash_threshold_reduction=[(.10, .25), (.20, .50), (.35, 1)],  # reduction rules
)

pf.dcf.cashflow_parameters = cwd

A carefully designed guardrail for deep drawdowns makes it possible to use more aggressive retirement portfolios with higher expected returns, but also higher volatility.

In future publications, we will explain in more detail how to apply VDS and CWD in practice.

EfficientFrontier: A Unified Class for Optimization with Rebalancing

The second key part of the release is the update to EfficientFrontier. We merged EfficientFrontier and EfficientFrontierReb into a single EfficientFrontier class. The Efficient Frontier is now built in a multi-period framework with rebalancing by default.

By caching intermediate solutions, using parallel computation, and optimizing the objective functions, we were able to speed up the calculations significantly.

In addition, optimization of rebalanced portfolios now supports bounds, that is, asset weight constraints. This is critical for practical applications: real-world portfolio models almost always require lower and upper bounds, not an abstract unconstrained solution.

ef = ok.EfficientFrontier(
    assets=["SPY.US", "GLD.US"],
    first_date="2004-12",
    last_date="2020-10",
    ccy="USD",
    rebalancing_strategy=ok.Rebalance(period="year"),
    n_points=40,
    ticker_names=True,
    bounds=((0.0, 1.0), (0.0, 0.20)),  # gold is capped at 20% in the portfolio
)

A fast way to find the solution for a target return:

ef.minimize_risk(target_value=0.11)

{'SPY.US': np.float64(0.9101000447520419),
 'GLD.US': np.float64(0.08989995524795805),
 'CAGR': 0.11,
 'Mean return': np.float64(0.11403419643168483),
 'Risk': np.float64(0.15083978371568296),
 'Weights': array([0.91010004, 0.08989996]),
 'iterations': 5}

Arbitrary Withdrawals and Contributions in All Strategies

Any withdrawal or contribution strategy now includes the time_series_dic parameter, which allows arbitrary cash flows to be set by calendar date.

time_series_dic = {
    "2027-02": 2_000,    # portfolio contribution in February 2027
    "2030-03": -4_000    # portfolio withdrawal in March 2030
}

Distribution Backtesting

Distribution backtesting is an important step before forecasting. New tools were added to make this process easier.

Automatic Distribution Selection

Version 2.0 introduces the kstest_for_all_distributions method, which runs the Kolmogorov–Smirnov test across all supported distributions and determines which one fits best.

pf.dcf.mc.kstest_for_all_distributions

Fitting Distribution Parameters

Any distribution parameter can now be set manually, either fully or partially.

This is especially important for the Student’s t distribution, which is often the best fit for modeling fat tails in forecasting.

For example, the parameters of the Student’s t distribution can now be set as follows:

pf.dcf.mc.distribution_parameters = (4.26, None, None)  # df, loc, scale

The degrees of freedom (df) are specified manually, while the other parameters are estimated automatically.

Moreover, the degrees of freedom can now be optimized automatically for a chosen forecast percentile:

pf.dcf.mc.optimize_df_for_students(var_level=5)  # optimize df for the 5th percentile

4.260007759068121

Q-Q Plot

The quality of distribution backtesting can be visualized with a Quantile–Quantile (Q-Q) plot, where historical data and generated data are compared.

Version 2.0 adds the plot_qq method for this purpose:

pf.dcf.mc.plot_qq(var_level=5)  # 5 is the confidence level for VaR and CVaR

If theoretical and empirical percentiles diverge too much at the selected percentile, it is better to fit the distribution parameters more carefully for a more accurate forecast. We will explain this process in detail in a separate article.

okama Documentation

The okama documentation is now cleaner and includes detailed information about all major additions, together with examples.

The examples section on GitHub has also been substantially improved:

04 investment portfolios with DCF.ipynb — many new examples for the VanguardDynamicSpending and CutWithdrawalsIfDrawdown withdrawal strategies
07 efficient frontier multi-period.ipynb — examples for the unified EfficientFrontier class and optimization with rebalancing
10 forecasting.ipynb — updated Monte Carlo forecasting examples, including distribution fitting methods

What’s Next for okama

In the near future, we will begin rolling the most important changes into okama.io.

Future versions of okama will include support for Pandas 3 and Python 3.14.

A somewhat longer-term goal is to create an equivalent of a personal financial plan built as a sequence of investment strategies. For example, an aggressive portfolio for building retirement savings followed by a conservative portfolio for spending in retirement. Naturally, the entire sequence of portfolios will need to be tested through Monte Carlo forecasting. We already have a plan for how to do that.

Sources

If you found the project useful, the easiest way to support it is to star it on GitHub.

Mastering Investment Portfolio Rebalancing with Python and Okama

Sergey Kikevich — Fri, 27 Jun 2025 04:58:01 +0000

Rebalancing is a crucial part of long-term portfolio management. As asset prices fluctuate, your investment portfolio can drift away from its target allocation, potentially increasing risk or reducing expected returns.

In this article, we’ll explore how to control asset weights within a portfolio using various rebalancing strategies using the okama Python library.

What is rebalancing?

Rebalancing is the process by which an investor restores their portfolio to its target allocation by selling and buying assets. After rebalancing all the assets have original (target) weights.

okama supports several investment portfolio rebalancing strategies. These strategies are divided into two types:

Calendar-based rebalancing
Rebalancing bands (threshold-based)

Calendar-based rebalancing

Calendar-based rebalancing is a strategy that involves adjusting the asset allocation of a portfolio at regular intervals, such as monthly, quarterly or annually.

Available periods for calendar-based strategies:

'month'
'quarter'
'half-year'
'year'

Rebalancing bands (threshold-based)

Rebalancing bands or threshold-based strategy is defined by absolute or relative deviation.

1. Absolute Deviation

Measures the simple difference (in percentage points) between current and target allocation.

Formula:

\text{Absolute Deviation} = \text{Current Weight} - \text{Target Weight}

Example:

Target: 40% bonds
Current: 45% bonds
Deviation: +5% (45% - 40%)

When to Use?

✔ Best for fixed rebalancing bands (e.g., "rebalance if ±5% from target")
✔ Simple for balanced portfolios (e.g., 60/40 stocks/bonds)

2. Relative Deviation

Measures deviation as a percentage of the target weight.

Formula:

\text{Relative Deviation} = \frac{\text{Current Weight - Target Weight}}{\text{Target Weight}} \times 100\%

Example:

Target: 10% gold
Current: 12% gold
Deviation: +20% ( $12%−10%10%\frac{12\%-10\%}{10\%}$ )

When to Use?

✔ Better for small allocations (e.g., 2% shift in 10% target = 20% relative change)
✔ Common in tactical allocation (sector tilts, alternative assets)

Key Comparison

Scenario	Absolute Deviation	Relative Deviation
Target 50%, Current 55%	+5%	+10%
Target 10%, Current 12%	+2%	+20%

Absolute: Treats all assets equally (5% shift triggers regardless of target weight)
Relative: More sensitive for small allocations (2% shift in 10% target = 20% signal)

No rebalancing ("Buy & hold")

If an investment strategy does not include rebalancing, asset weights in the portfolio may drift arbitrarily from their initial targets.

Why Use Okama?

Okama is an open-source Python library for investment portfolio analysis. It provides tools for:

Portfolio construction and analysis
Asset allocation and rebalancing
Risk and performance metrics
Visualization
All approaches comply with CFA guidelines

A detailed description of the Okama library can be found in the previous article.
Let’s dive into a practical example.

Setting Up

First, install Okama via pip:

pip install okama

Import packages:

import warnings

warnings.filterwarnings("ignore")

import matplotlib.pyplot as plt

plt.rcParams["figure.figsize"] = [12.0, 6.0]

import okama as ok

import pandas as pd

pd.options.display.float_format = "{:,.5f}".format

Setting a rebalancing strategy

The Rebalance class is used to configure rebalancing strategies.

A basic calendar-based portfolio rebalancing strategy (executed annually) can be configured as follows:

#  set up a calendar-based rebalancing strategy where the period is 1 year
reb_calendar = ok.Rebalance(period="year")

Okama works with montly data series. If the rebalancing period is equal to a month we have the classic Markowitz situation with always rebalanced portfolio where the weights do not deviate from the target.

reb_calendar_month = ok.Rebalance(
    period="month",  #  set up a calendar-based rebalancing strategy where the period is 1 month
    abs_deviation=None,
    rel_deviation=None
    )

The same for a rebalancing bands (threshold-based) strategy with 5% absolute deviation:

#  set up a rebalancing bands strategy with allowed absolute deviation 5%
reb_bands_abs = ok.Rebalance(
    abs_deviation=0.05
)

The strategy with relative deviation 10%:

#  set up a rebalancing bands strategy with allowed relative deviation 10%
reb_bands_rel = ok.Rebalance(
    rel_deviation=0.10
)

All rebalancing strategies can be combined:

reb = ok.Rebalance(period="half-year", abs_deviation=0.15, rel_deviation=0.10)
reb

Output:

period           half-year
abs_deviation      0.15000
rel_deviation      0.10000
dtype: object

In hybrid strategies, a calendar principle is applied (for example, once a year). But rebalancing triggers only if the deviation in weight of one of the assets exceeds the condition. This resembles how it happens in real investor life.

To configure a strategy without rebalancing:

no_reb = ok.Rebalance(period="none")
no_reb

Output:

period           none
abs_deviation    None
rel_deviation    None
dtype: object

Rebalancing strategies in Portfolio

All rebalancing strategies are available in Portfolio class of okama and can be used for backtesting or forecasting. In okama all rebalancings occure in the end of period (the last day of month, last month of year etc.)

The condition for rebalancing bands is verified in the end of every month as okama uses monthly data.

60/40 Portfolio

What does the 'ideal portfolio' look like? From the perspective of risk control, in an 'ideal' portfolio, the proportions of the assets should be constants.

Let's set up a simple 60/40 portfolio with popular bonds and stocks ETFs.

target_weights = [0.60, 0.40]
pf2 = ok.Portfolio(
    ["AGG.US", "SPY.US"],
    weights=target_weights,
    last_date="2025-06",
    ccy="USD",
    rebalancing_strategy=reb_calendar_month,  # always rebalanced
    inflation=False,
)
pf2

Output:

symbol                        portfolio_8100.PF
assets                         [AGG.US, SPY.US]
weights                              [0.6, 0.4]
rebalancing_period                         month
rebalancing_abs_deviation                  None
rebalancing_rel_deviation                  None
currency                                    USD
inflation                                  None
first_date                              2003-10
last_date                               2025-06
period_length                21 years, 9 months
dtype: object

Portfolio.weights_ts property shows how the portfolio weights changed in the past. For this set of securities, 21 years of historical data are available.

weights_no_rebalancing = pf2.weights_ts
weights_no_rebalancing.plot();

And this is exactly how it has always been presented in the classical Modern Portfolio Theory (MPT) of Markowitz. However, in real live the weights changes.

The opposite case is when the weights change without constraints (not rebalanced portfolio).

# change the rebalancing strategy
pf2.rebalancing_strategy = no_reb
# plot the weights
pf2.weights_ts.plot();

Over several years, the conservative portfolio became aggressive as stock allocations grew.

abs(pf2.weights_ts - target_weights)["SPY.US"].max()

Output:

np.float64(0.36386072210732423)

The weights deviate 36% from the initial allocation.

We can switch the rebalancing strategy in an existing portfolio to calendar-based rebalancing (annual frequency) and try to keep the risk ander control.

pf2.rebalancing_strategy = reb_calendar
pf2

Output:

symbol                        portfolio_8100.PF
assets                         [AGG.US, SPY.US]
weights                              [0.6, 0.4]
rebalancing_period                         year
rebalancing_abs_deviation                  None
rebalancing_rel_deviation                  None
currency                                    USD
inflation                                  None
first_date                              2003-10
last_date                               2025-06
period_length                21 years, 9 months
dtype: object

Portfolio.rebalancing_events property shows the rebalancing events on the historical data:

ev = pf2.rebalancing_events
ev

Output:

2003-12    calendar
2004-12    calendar
2005-12    calendar
2006-12    calendar
2007-12    calendar
2008-12    calendar
2009-12    calendar
2010-12    calendar
2011-12    calendar
2012-12    calendar
2013-12    calendar
2014-12    calendar
2015-12    calendar
2016-12    calendar
2017-12    calendar
2018-12    calendar
2019-12    calendar
2020-12    calendar
2021-12    calendar
2022-12    calendar
2023-12    calendar
2024-12    calendar
Freq: M, dtype: object

There were 22 rebalancing events:

ev.shape  # 22 rebalancing events

Output:

(22,)

We can plot all of them to see when rebalances occurred.:

fig = plt.figure(figsize=(12, 6))
ax = plt.gca()
pf2.weights_ts.plot(ax=ax)
ax.vlines(x=ev[ev == "calendar"].index, ymin=0, ymax=1, colors="blue", ls="--", lw=1, label="Rebalancing events")
ax.set_ylim([0, 1])
ax.legend();

Let's see top 5 weights devations:

abs(pf2.weights_ts - target_weights)["SPY.US"].nlargest(n=5)

Output:

2008-12   0.11913
2008-11   0.10794
2008-10   0.08644
2013-12   0.07366
2021-12   0.06630
Freq: M, Name: SPY.US, dtype: float64

The maximum asset weight deviation occurred in 2008 during the financial crisis, reaching almost 12%. This was significantly lower than in the non-rebalanced scenario.

Let's see what happens if we set the rebalancing bands with an absolute limit of 5%:

pf2.rebalancing_strategy = reb_bands_abs
pf2

Output:

symbol                        portfolio_8100.PF
assets                         [AGG.US, SPY.US]
weights                              [0.6, 0.4]
rebalancing_period                         none
rebalancing_abs_deviation               0.05000
rebalancing_rel_deviation                  None
currency                                    USD
inflation                                  None
first_date                              2003-10
last_date                               2025-06
period_length                21 years, 9 months
dtype: object

Now the number of rebalancing events is 13 now.

ev = pf2.rebalancing_events
ev

Output:

2005-11    abs
2008-10    abs
2009-01    abs
2009-09    abs
2011-04    abs
2011-09    abs
2012-03    abs
2013-10    abs
2016-11    abs
2018-01    abs
2021-02    abs
2021-12    abs
2024-03    abs
Freq: M, dtype: object

ev.shape

Output:

(13,)

13 rebalancings occurred during the historical period - fewer than the 22 required under calendar-based rebalancing. In real-world finance, each rebalancing incurs costs (brokerage commissions, taxes). This represents substantial savings...

fig = plt.figure(figsize=(12, 6))
ax = plt.gca()
pf2.weights_ts.plot(ax=ax)
ax.vlines(x=ev[ev == "abs"].index, ymin=0, ymax=1, colors="blue", ls="--", lw=1, label="Rebalancing events")
ax.set_ylim([0, 1])
ax.legend();

abs(pf2.weights_ts - target_weights)["SPY.US"].nlargest(n=5)

Output:

2008-10   0.06851
2018-01   0.06004
2021-12   0.05638
2013-10   0.05638
2024-03   0.05448
Freq: M, Name: SPY.US, dtype: float64

Weight deviations are now under control. The maximum deviation reached 6.9% - nearly half of what occurred with calendar rebalancing. Interestingly, this still exceeds the strategy's 5% limit. This occurs because okama checks rebalancing conditions at month-end (using monthly data). Within a single month, asset weights can drift beyond the strategy's prescribed limits.

3 assets Portfolio with small allocation

We can test the same rebalancing strategy with absolute weight deviation limits in a 3-asset portfolio, where one asset (gold) has just a 5% allocation.

# set target weights for the assets
target_weights3 = [0.60, 0.35, 0.05]
# set the rebalancing strategy
rs3 = ok.Rebalance(
    period="none", 
    abs_deviation=0.10, 
    rel_deviation=None
    )

# make a portfolio with 3 assets
pf3 = ok.Portfolio(
    ["SP500TR.INDX", "VBMFX.US", "GC.COMM"],
    weights=target_weights3,
    ccy="USD",
    rebalancing_strategy=rs3,
    inflation=False,
)
pf3

Output:

symbol                                       portfolio_1335.PF
assets                       [SP500TR.INDX, VBMFX.US, GC.COMM]
weights                                      [0.6, 0.35, 0.05]
rebalancing_period                                        none
rebalancing_abs_deviation                              0.10000
rebalancing_rel_deviation                                 None
currency                                                   USD
inflation                                                 None
first_date                                             1988-02
last_date                                              2025-06
period_length                               37 years, 5 months
dtype: object

During backtesting, the rebalancing condition was triggered 8 times.

ev3 = pf3.rebalancing_events
ev3

Output:

1995-07    abs
1997-07    abs
2002-09    abs
2007-01    abs
2008-10    abs
2013-12    abs
2018-08    abs
2023-06    abs
Freq: M, dtype: object

ev3.count()

Output:

np.int64(8)

We can see these rebalancing events in the chart.

fig = plt.figure(figsize=(12, 6))
ax = plt.gca()
pf3.weights_ts.plot(ax=ax)
ax.vlines(x=ev3.index, ymin=0, ymax=1, colors="blue", ls="--", lw=1, label="Rebalancing by abs")
ax.set_ylim([0, 1])
ax.legend();

However there were situations when the deviation for gold was large. The max deviation is 4,3% which is almost double (!) from the target allocation.

abs(pf3.weights_ts - target_weights3).max()

Output:

Symbols
SP500TR.INDX   0.10438
VBMFX.US       0.10640
GC.COMM        0.04257
dtype: float64

In this case we should add relative deviation band to control better the allocaction for gold.

pf3.rebalancing_strategy = ok.Rebalance(
    period="none", 
    abs_deviation=0.10, 
    rel_deviation=0.30)

The number of rebalancing increased to 14.

ev3 = pf3.rebalancing_events
ev3.shape

Output:

(14,)

ev3

Output:

1989-05    rel
1992-04    rel
1996-06    rel
1997-07    rel
1999-01    rel
2002-07    abs
2006-01    rel
2008-01    rel
2008-12    abs
2011-07    rel
2013-06    rel
2017-10    abs
2021-08    abs
2025-03    rel
Freq: M, dtype: object

Now we have 10 rebalancings by relative band and only 4 by absolute.

ev3[ev3 == "rel"].count()

Output:

np.int64(10)

ev3[ev3 == "abs"].count()

Output:

np.int64(4)

New rebalancing events are market with green color in the chart.

fig = plt.figure(figsize=(12, 6))
ax = plt.gca()
pf3.weights_ts.plot(ax=ax)
ax.vlines(x=ev3[ev3 == "abs"].index, ymin=0, ymax=1, colors="blue", ls="--", lw=1, label="Rebalancing by abs")
ax.vlines(x=ev3[ev3 == "rel"].index, ymin=0, ymax=1, colors="green", ls="--", lw=1, label="Rebalancing by rel")
ax.set_ylim([0, 1])
ax.legend();

Now the max deviation of gold is 2,2%. And it looks better.

abs(pf3.weights_ts - target_weights3).max()

Symbols
SP500TR.INDX   0.11944
VBMFX.US       0.11290
GC.COMM        0.02217
dtype: float64

We can test an alternative approach: implementing calendar-based rebalancing that only triggers when absolute or relative deviation thresholds are breached. This hybrid method is commonly used in practice, eliminating the need for constant weight monitoring. Instead, investors simply review their allocation once a year (or once a half-year).

pf3.rebalancing_strategy = ok.Rebalance(
    period="year", 
    abs_deviation=0.10, 
    rel_deviation=0.20
)

The number of rebalancing events has increase by 2.

ev3 = pf3.rebalancing_events
ev3.shape

Output:

(16,)

In the events table we can see that rebalncings happen only in december.

ev3

Output:

1989-12    rel
1991-12    rel
1995-12    rel
1997-12    rel
1999-12    rel
2001-12    rel
2002-12    rel
2006-12    rel
2007-12    rel
2008-12    abs
2011-12    rel
2013-12    abs
2015-12    rel
2019-12    rel
2021-12    rel
2024-12    rel
Freq: M, dtype: object

Most of them are triggered by the relative band. If one feel safe with larger deviations the number of events can be reduced by adjusting the rel_deviation parameter.

ev3[ev3 == "rel"].count()

Output:

np.int64(14)

ev3[ev3 == "abs"].count()

Output:

np.int64(2)

fig = plt.figure(figsize=(12, 6))
ax = plt.gca()
pf3.weights_ts.plot(ax=ax)
ax.vlines(x=ev3[ev3 == "abs"].index, ymin=0, ymax=1, colors="blue", ls="--", lw=1, label="Rebalancing by abs")
ax.vlines(x=ev3[ev3 == "rel"].index, ymin=0, ymax=1, colors="green", ls="--", lw=1, label="Rebalancing by rel")
ax.set_ylim([0, 1])
ax.legend();

In the chart we can see that there were several long periods without rebalancing.

And the max deviation is still under control.

abs(pf3.weights_ts - target_weights3).max()

Output:

Symbols
SP500TR.INDX   0.12670
VBMFX.US       0.11787
GC.COMM        0.02512
dtype: float64

For a passive investment approach, where the need for portfolio rebalancing is checked without automation tools, a hybrid approach with long intervals (a year or half a year) is convenient in one sense, as it eliminates the need to constantly monitor weight deviations. On the other hand, deviation bands still prevent the portfolio from straying too far from the intended strategy.

At the same time, the larger the allowed weight deviations, the greater the potential bonus from rebalancing in the form of additional returns.

The Rebalancing Bonus: Excess Return

According to research by William Bernstein, rebalancing not only provides the obvious benefit of risk control, but can also deliver a considerable excess return. This effect occurs if the portfolio contains assets with low correlation. The okama library allows to study the impact of rebalancing strategies on this excess return and optimize your asset allocation accordingly. If you’re interested in this topic, let me know—I’ll explain how to do this in the next article.

Open-source in finance. Okama project

Sergey Kikevich — Thu, 10 Feb 2022 11:52:50 +0000

There is an interesting paradox in fintech projects. It is hardly possible to find an area where more investments come. Therefore, the most advanced technologies are concentrated here: blockchain, AI, big data, etc. On the other hand, in the financial area one can found few well-developed open-source projects. There are such advanced commercial software products as the Bloomberg Terminal, special programming languages that were developed specifically for finance. But on GitHub you can count on the fingers popular open-source financial projects. The availability of financial data also lags other areas. Of course, there is an excellent World Bank open database. No less good is the FRED project of the US Federal Reserve. But such projects are unique and not very common. It is difficult to obtain up-to-date macroeconomic data. The historical market data is available only in paid subscriptions. In the 21st century almost every big company supports open-source projects, makes data available with open APIs... even Microsoft has changed its mind regarding open-source. But in finance, everything remains like it was in the 90s. Why is it so? Perhaps fintech projects are too focused on making quick money. For them, mythical unicorns are more important, and there is simply not enough time for topics like sustainable development.

It seems to me that in financial projects, as well as in any other field, it is time to accept that a competitive edge is not about having some “secret” software and exclusive access to closed databases. The expertise and experience of the person who uses these software products should be the main value. And it is high time to make the data as open and free as possible.

okama project

Our small project is an attempt to bring together all the commonly used financial algorithms for time series and provide them for free along with historical data. We were selecting approaches basing on CFA program for Quantitative Finance. Considering the popularity of the Modern Portfolio Theory and asset allocation, we started with this topic. okama is an open-source package for Python.

Portfolios in okama can include securities with different domestic currencies. All portfolio properties are adjusted to the base currency.

After installing the package (pip install okama) and importing it (import okama as ok) stocks/bonds ETF portfolio one can easily create:

ok.Portfolio(['SPY.US', 'BND.US'])

If not specified all the securities weights are equal. However, it easy to create 60/40 allocation using weights argument:

ok.Portfolio(['SPY.US', 'BND.US'], weights=[.60, .40])

By default, the base currency is USD for portfolio. All risk and return parameteters are calculated in base currency. But you can create portfolios with several popular currencies (EUR, GBP, ILS, RUB etc.) and have all the metrics adjusted.

Let’s add a popular European ETF and set EUR as a base currency of portfolio:

pf = ok.Portfolio(
    ['SPY.US', 'BND.US', 'DBXD.XFRA'], 
    weights=[.40, .30, .30], 
    ccy='EUR'
)

A list of security names, tickers and weights are available in a single table:

pf.table

The accumulated return for the portfolio vs inflation:

pf.wealth_index.plot()

Summary table with key indicators:

pf.describe()

Other okama examples are available in Jupyter Notebook format.

The main features of okama:

Investment portfolio constrained Markowitz Mean-Variance Analysis (MVA) and optimization
Rebalanced portfolio optimization with constraints (multi-period Efficient Frontier)
Monte Carlo Simulations for financial assets and investment portfolios
Popular risk metrics: VAR, CVaR, semi-deviation, variance and drawdowns
Financial ratios: Beta, Sharpe, Sortino etc.
Forecasting models according to normal and lognormal distribution
Testing distribution on historical data
Dividend yield and other dividend indicators for stocks
Backtesting and comparing historical performance of broad range of assets and indexes in multiple currencies
Methods to track the performance of index funds (ETF) and compare them with benchmarks
Main macroeconomic indicators: inflation, central banks rates
Matplotlib visualization scripts for the Efficient Frontier, Transition map and assets risk / return performance

Working on the package we were inspired by Portfolio Visualizer project. The idea was to create open-source version with the similar functionality and free international historical data.
okama GitHub page: https://github.com/mbk-dev/okama
Documentation on Read The Docs: https://okama.readthedocs.io