Flexible Retirement Planner Support Forum

My father has a pension with a fixed payout and a variable annuity piece that pays roughly 70% of the return of a mutual fund. I can easily handle the fixed part in frp, but the pension option in the additional data window only allows a cola and not the annualized return and standard deviation for an asset. How can this sort of income be handled in FRP?

This is tough to model well in FRP. I think the closest approximation would be to set up a fixed COLA pension, then try to pick a conservative COLA percent value.

Another approach, that's very messy, might be to try to model the variable part of the annuity using the tax free portfolio (assuming this isn't getting used). I'm not sure I'd even recommend this because it's so complicated, but basically you'd start with a lump sum in the tax free portfolio that's big enough to generate the variable cash flow, then create a cash flow in the last year of the plan to remove the original lump sum (adjusted for inflation). I'm not entirely clear this is workable, but it may be worth exploring if you really want to model the variability of the annuity cash flow.

Thanks. Those ideas fit with what I have been thinking, but of course they do not take the variability of the "variable annuity" into account, which is the main reason I want to include it as it is instead of as a steady income flow. Doesn't seem like it would be too hard for FRP to have more than one option for each account type.

For example, with my own annuity, since there is no tax on capital gain in the annuity, but the income taken out is taxable, this acts like a tax deferred account. However, for the first 15 years only 1/3 is taxable, then 100% is. So I'd need to set up two extra tax deferred accounts...one with 1/3 of the income taxable and then a new one that's 100% taxed on the payment.

In the FRP details output, the tax deferred column could combine all the tax deferred accounts to save room, or they could be listed in three separate columns. I would not have a problem with either. But this way the variability of the variable annuity could nicely be taken onto account.

Which leaves a question. How does FRP handle variability? Obviously it can't calculate the variability of the combined accounts because it would need to calculate covariances to do so. That would mean using the historical data, etc. Does it simulate the total portfolio value over each of the thousands of iterations and then calculate the standard deviation of those? So how does the software arrive at the confidence bands around the mean for the whole portfolio over the years?

Packjac2000 wrote:Which leaves a question. How does FRP handle variability? Obviously it can't calculate the variability of the combined accounts because it would need to calculate covariances to do so. That would mean using the historical data, etc. Does it simulate the total portfolio value over each of the thousands of iterations and then calculate the standard deviation of those? So how does the software arrive at the confidence bands around the mean for the whole portfolio over the years?

The simulation's approach to the variability of returns is relatively simple. In each year of each iteration of the simulation, the planner generates one or more random numbers to determine the portfolio return(s) used for that year/iteration. The random number(s) generated get scaled based on the average return and standard deviation inputs to generate portfolio return(s).

For years when the inputs are configured to use a common return for all portfolios, one random number is generated for each year/iteration of the simulation. For years when the inputs are configured to use separate returns for one or more portfolio types, multiple random numbers are generated.

When multiple returns are generated, they are generated independently of each other and no assumptions are made about co-variances between the multiple returns. This is a necessary simplifying assumption that's unrealistic in real life. Unfortunately, any attempt to accurately model the connection between the returns would be extremely complicated and would likely introduce so much modeling error that it would negate any added precision.