Issue when retirement income is zero.

[SpinolaHours]

Hello,

I'm trying to model a life cycle consumption model (specifically ConsRiskyContribModel.py).

I need to set retirement income to zero but when I do that all of the other sate variables also become zero. I believe this is because consumption, risky assets etc are normalised in terms of the permament income.

Is there a way to handle this correctly? Even setting retirement close to zero causes some funky behaviour.

Thanks for any help.

[mnwhite]

I'm running out the door right now and will answer more fully later, but as a quick answer:

When permanent income goes to zero, an agent's normalized market resources go to infinity. When permanent income drops to almost zero (say, 1e-9), then their normalized market resources become absurdly large. In most HARK models, such an agent should behave like a perfect foresight consumer. With a risky asset, my guess is that they should consume a constant fraction of their wealth each period, and to set their risky asset share at the Merton-Samuelson limit.

With a friction in re-allocating assets, I'm not sure how that would work. I forget how the friction in RiskyContrib model works off the top of my head, but will look at it tonight and provide a more complete answer. My guess is that the way to do this and not have it break is not to have PermGroFac of (near) zero, but instead have transitory shocks all go at or near zero and PermGroFac stays at 1. Most HARK models are set up to correctly handle E[TranShk] != 1, but I'm not sure about RiskyContrib. I'll take a look and provide more feedback.

[mnwhite]

Ok, I've had a chance to remind myself what this model is. There are two sources of friction:

1. The agent has to pay a proportional tax tau when they withdraw from the risky asset into the safe asset.
2. The agent might not have a chance to do that in any given period.

Agents can also set a constant "contribution rate" that puts a fraction of their labor income into the risky asset; they can only choose a new value of it when they also have a chance to withdraw from the risky asset.

Looking at the model and the code, my suggestion to use transitory shocks to set income to be near zero should work. If you're using the default "lifecycle" income process, the quick and easy way to do this is to set UnempPrbRet = 1.0-1e-15 and IncUnemp = 0.0, with PermGroFac[t]=1.0 in all retirement periods. That will make it so that at any age after T_retire, the agent will almost surely receive zero income, but permanent income won't go crazy.

When the model is being solved, retired agents foresee that there is a one in a quadrillion chance that they will receive one quadrillion times their retirement salary (more or less), and the rest of the time they will receive no income. As long as they aren't extremely risk tolerant (like CRRA = 0.1), the remote prospect of an insane payday won't matter to them and they will act almost as if income were surely zero.

When the model is being simulated, there will indeed be a one in a quadrillion chance that any given retired agent will get a quadrillion times their permanent income at retirement. But even if you simulated one million agents for a thousand periods, there would still only be a one in a million chance that anyone ever hits the jackpot. If they do, just change the seed on your RNG and try again. If it happens twice... go out and buy a lottery ticket immediately.

Let me know if this works. There's a more involved way if it doesn't.

My broader piece of advice here is that using RiskyContrib in the retirement periods is probably overkill. If labor income is going to zero, I'd wager that the withdrawal tax tau is also zero in retirement (unless your model government is a jerk). If that's the case, then there's little point in solving 30-50 retirement periods of a model with three state variables and two continuous controls. If you allow the simplification that retired agents have enough free time that they can manage their portfolio in every period, then the "retirement phase" reduces to a consumption-saving-portfolio problem with no non-capital income. That model has a closed form solution that you can construct for effectively zero computational cost.

[SpinolaHours]

Thank you for such a prompt and detailed response!

I've tried setting the UnempPrbRet and IncUnemp as you suggested and the income behaves as expected. I should be able to achieve my desired income profile from this. Appreciate the help.

To your broader points. I am trying to model a realistic scenario for wealth management. The features that I'll likely need include:

• Simulating early retirement with no income, as discussed above. I would expect to generally have a period of employment before this.
• Taxation of risky assets approximating a capital gains tax (yes unfortunately my government are jerks!).
• Flexibilty to add bequests.

I've only just started to delve into these models. Would you recommend splitting the problem into working and retirement stages and then solve the retirement section with the closed form solution?

Also I'm wondering if I'm better off starting with the bequest model and then adding some custom tax logic given the tax logic would need some additional flexibility?

Appreciate these questions are outside the scope of the initial discussion.

[mnwhite]

Sorry I forgot to respond to this @SpinolaHours . How you should proceed in terms of the model depends on what your goals are with the project-- not the model features, but what you want to address / explore. In general, you want to focus your "complexity costs" on the part of the model that's closest to what you're interested in. If you're strictly interested in the behavior of people who are still working and accumulating wealth, then I would suggest doing the simplest possible "retired model" and just dropping in the 0th period of its solution as the "terminal" solution for the working model. If you care about the behavior of / outcomes for people in retirement, then you would want to include a "proper model" for them.

It's a little more complicated if you want early retirement to be a choice, because there's difficulties that arise with continuous-discrete choice models (that you're probably aware of). I don't think we've actually included a discrete choice labor model in HARK, but there is a very (very) old, possibly deleted branch where I worked on it. It's not as nasty if you have retirement as a once-and-for-all decision, but still not simple.

Adding a bequest motive is easy, if that's what you mean by "flexibility to add bequests". So I would recommend starting with the HARK model that has harder features (RiskyContrib) that you want to include, and then add the easier features (bequest motive) rather than vice versa. Also, if you don't care about the specific frictions that Mateo included in RiskyContrib, then see HARK.ConsBequestModel.BequestWarmGlowConsumerType, which has basic portfolio allocation plus a bequest motive. Adding a tax system on top of that would not be hard.