Page 1 of 1

Changing the way "Spending Inputs" are treated

Posted: Mon May 19, 2014 1:41 pm
by bo_knows
I wanted to separate this discussion into it's own thread. Dihard summarized a lot of this in this specific post: viewtopic.php?f=3&t=133&start=20#p958

Firstly, I don't want to have too many options for the user to choose. Secondly, I think that the way that Spending Inputs are treated now (simply as "Portfolio Adjustments" with no impact to the "Spending" numbers) should be the default option.

So, I like the idea of #4 in that post:

4) Dynamic optimized withdrawals
Pros - minimizes portfolio drag compared to option1, minimizes drawing from bad years as much as possible compared to option2 (sensitive to the market), takes user's 'necessities' spending into account so we know exactly what they are able to set aside, ability to prescribe a spending/allocating cutoff*, like 2) this is also better for further away purchases
Cons - higher complexity, while safer against overdrawing than 2) the risk is still not as safe as 1)

* This is a unique benefit I just thought of. Before I had said the user enters a 'necessity floor spending level' and we tell them if the required re-allocations for the purchase are feasible 100% (or less) of the time. However, doing the reverse of what I said is actually more useful: Since we can calculate the aggregate spending allowed before the purchase date for each cycle and we know the purchase amount, we could feasibly calculate the maximum the user can spend on 'necessities' (ie everything else but the purchase allocations) each year while saving just enough for the purchase 100% of the time (historically).

So say you run a 4%ofPort simulation with a spending input, we can say "If you save everything above x$ of your yearly spending limit in a cash account you will have enough to afford Spending Input 1 (100% according to history)". For multiple inputs with multiple dates you would get a list of gradually increasing floor amounts as you pass each purchase.

But, I have some concerns still.

- You'd have to have a separate "necessities" or "floor spending" for every Withdrawal Method
- This method, and having a "floor spending", doesn't necessarily jive with some of the constant withdrawal methods (like the standard inflation-adjusted spending). If you tell cFIREsim that you want $40k/yr in inflation-adjusted spending forever, how do you skim money off that for these extra purchases?
- If we use the 4% of Portfolio spending as an example, and say we're trying to save $100k for a housing upgrade, if the "extra" money beyond necessities is not enough to pull together $100k by the needed date, what's the backup? Keeping track of each individual spending decision and telling the user whether it failed, isn't necessarily practical. Also, in this case, it's not practical in terms of the simulation to get to the point where this fails and then decide you should have set aside $X from the get-go to make this work.

My current stance:

What if we just have 2 options for each Spending Input? Neither of which will affect the "Spending" charts/totals. This appears to be the simplest way forward, and we can continue to talk about possible dynamic methods.

(o) Take out as a "Portfolio Adjustment", at desired date
( ) Put into cash reserve immediately at retirement date, and withdraw at desired date