Skip to content

Withdrawal sequencing and the DP optimizer

Where Haven pulls money from in retirement — the greedy default and the DP-optimized strategy that searches for a better path.

Last updated

More in Planning Strategies

In accumulation, the question is "where do I put the next dollar?" In retirement, it flips: "where do I take the next dollar from?" Same dollar amount of spending can cost you very different amounts of tax depending on which account you tap first, and that difference compounds over a thirty-year drawdown into real money.

Why sequencing matters

The retirement withdrawal problem has three forces pulling against each other:

  • Tax drag. Pulling from a tax-deferred account (401(k), Traditional IRA, RRSP) generates ordinary income; pulling from a brokerage generates capital gains; pulling from a Roth or TFSA generates nothing. Same spending, very different tax bills.
  • RMDs and forced distributions. Once required minimum distributions kick in, you no longer have full discretion over what comes out of tax-deferred accounts. Whatever you didn't draw down voluntarily in your low-income years comes out anyway, often at a higher bracket.
  • Bracket management. Income tax is progressive. Smoothing income across years — pulling a little tax-deferred every year instead of all at the end — can keep you in lower brackets the whole way through.

Get sequencing right and you can extend portfolio life by years on the same starting balance. Get it wrong and you donate a meaningful slice of your savings to taxes you didn't have to pay.

Greedy default

Haven's default sequencing is greedy: each year, fill the spending gap from accounts in a fixed priority order, taking from one bucket until it's empty (or until a constraint stops you), then moving to the next. The default order generally pulls from taxable first, then tax-deferred, then tax-free — the textbook "let the Roth/TFSA grow longest" heuristic.

Greedy is available on every paid display tier (Family and Pro). It's fast, it's predictable, and for the majority of plans it lands within a few percent of optimal. Most people should start here, see what the model does, and only reach for a smarter strategy if the answer feels wrong or the lifetime tax number looks high.

The greedy strategy doesn't try to outsmart RMDs or hunt for conversion windows. It executes the priority order year by year. That's its strength (transparent, explainable) and its weakness (it can leave money on the table by not looking ahead).

DP-optimized

The DP (dynamic programming) optimizer searches a much richer space. Instead of following a fixed priority order, it considers, for each year, multiple combinations of how much to draw from each account type — and chooses the combination that minimises lifetime tax across the whole horizon, not just this year's bill.

The DP optimizer is gated to Family or Pro (internal planDPOptimizer, which resolves to "Pro-or-above" in the entitlements layer — meaning Family and Pro both qualify). It's the same gate as the rest of the Plan engine's heaviest features, because the search itself is computationally meaningful and because the optimization mostly pays off for households with multiple account types and a long horizon.

What the optimizer actually searches over:

  • Account types. How much to pull this year from taxable brokerage, from tax-deferred (401(k), Traditional IRA, RRSP), and from tax-free (Roth, TFSA), in combinations rather than strict priority order.
  • Conversion windows. Years where it's cheaper to convert tax-deferred to tax-free at today's bracket than to wait and pay tomorrow's higher bracket on the same dollar.
  • Claiming dates. When to start CPP / Social Security, treating the claiming age as part of the optimization rather than a fixed input.

What it doesn't search over:

  • Behavioural preferences. You might want to leave Roth or TFSA balances untouched for heirs; the optimizer doesn't know that and will spend them down if the math says to. If you have a reason a pure tax-minimisation answer ignores, you'll need to constrain the inputs (or just stick with greedy).
  • Risk tolerance. It minimises expected lifetime tax under the model's assumptions, not regret under bad outcomes. If you're worried about sequence-of-returns risk, the optimizer's answer isn't a substitute for keeping a cash buffer.
  • Things outside the plan. Charitable giving strategies, QCDs, donor-advised funds, life insurance — none of those are in the optimizer's search space. If they're part of your real strategy, treat the optimizer's output as a baseline you then adjust.

Reading the resulting schedule

When you switch from greedy to DP-optimized, the Plan re-runs and the right-panel Flow view updates to show the new withdrawal mix. A few things to look for:

  • Which accounts are getting touched in early retirement. A common DP outcome: the optimizer pulls more tax-deferred earlier (filling up low brackets while you can) and saves taxable for later. This often surprises people because it inverts the textbook "tax-deferred last" heuristic.
  • Conversion years. If the optimizer is doing Roth conversions, you'll see chunky tax-deferred withdrawals in low-income years that immediately route to tax-free instead of being spent. Those are conversions, not living expenses.
  • The lifetime tax number. Compare the totals between greedy and DP-optimized. The headline savings can be material for households with significant tax-deferred balances; for plans dominated by taxable accounts, the gap is often small.

For the underlying engine internals — how withdrawals are composed year by year, how tax estimation is layered in, how the projection composes — see how the engine composes withdrawals.

The short version: greedy gets most people most of the way there. DP earns its keep when you have a multi-account, multi-decade drawdown with real bracket-management opportunities. Try both, look at the lifetime tax number, and pick the one whose answer you understand and trust.

Was this helpful?

Was this article helpful?

Still stuck? Email support@havenfinance.app.