In a model with stochastic probabilities of dying some people will die while they have assets. To avoid the model leaking assets we need to do something with them. The most popular thing is to give them to younger households as ‘bequests’, which additionally has the advantage that bequests are realistic and of direct interest themselves.
The most basic approach is just to collect all the ‘bequests left’ (in VFI Toolkit you can just do this with a FnsToEvaluate). You can then lump-sum transfer these to everyone else (set up a Params.BequestRec that everyone gets). In general eqm you make sure that ‘bequests left’ equals ‘bequests received’.
What can we do for a bit more realism?
First, use a warm-glow of bequests function that makes bequests a luxury-good, to fit the empirical evidence that richer households leave more-than-proportionally larger bequests. De Nardi (2004) introduces this with a warm-glow of bequests function of \phi (1+ \frac{aprime}{\psi})^{1-\sigma}. \phi controls the strength of the bequest motive, \psi determines how much of a luxury it is, \sigma is often set equal to the curvature of utility in consumption (but doesn’t have to be). [Warm-glow originates with Andreoni (1989), De Nardi introduces it as a luxury-good in OLG models.] Adding a warm-glow of bequests also tends to improve models empirically in the sense that it means older household hold more assets.
In the basic setup we just give these bequests to everyone. Let’s walk through some alternatives.
How about if we wanted to make it so that only people aged 45-60 get bequests (based on some data we can see which ages are relevant). The easiest way is just to make it so that the bequest received is now ‘beq_j times BequestRec’, where BequestRec is a parameter as before that we determine in general eqm so that total bequests received equal total bequests left. ‘beq_j’ is also a parameter, but an age-dependent parameter, you could set it to zeros for all ages except 45-60 where it is one, with this setup only people aged 45-60 get bequests (and they all get the same bequest). You could even have beq_j be, say 0.5 for ages 45-49 and 1.5 50-54, and 1 55-60 so that some ages receive bigger bequests. [Note that in this setup we want a FnToEvaluate for ‘beq_j times BequestRec’, and this is what we use in general eqm to equal bequests left.]
If you want that households get a bequest once, at an unknown age, you need to track who has received bequests so that they don’t get another. You could do this, e.g., by setting up a markov z shock that can take three values, call them z_grid=[0,1,2]', and set pi_z=[1-p,p,0; 0,0,1; 0,0,1]. The idea is that z=0 represents no bequest yet, z=1 represents get a bequest this period, and z=2 represents already got a bequest. The transitions mean you have probability p of getting a bequest, and once you receive a bequest you go to z=2 with certainty and stay there. Note that you can set this up with an age-dependent pi_z, so you can make p differ by age (including p=0 so young/old people don’t get bequests). You would then set up the return fn so you only get ‘BequestRec’ parameter when z=1.
All of the above has bequests being of a fixed known size. What if we want small, medium and large bequests? You could use the markov approach, but throw in more points in the middle. Say z_grid=[0,0.5,1,1.5,2]', and the 0.5,1,1.5 represent different sizes of bequest. You would have pi_z=[1-p1-p2-p3,p1,p2,p3,0; 0,0,0,0,1; 0,0,0,0,1; 0,0,0,0,1; 0,0,0,0,1] (there are probabilities p1,p2,p3 of receiving the small,medium,large bequests; once you get a bequest you move to the absorbing z=2 state that represents having received a bequest).
What if we want the size of bequests to ‘correlate’ between parent and child. Say we want two types of households, high income and low income, and we want high income households to leave bequests to high income households, and similarly low income households leave bequests to low income households. This is easy if you set up the two households as permanent types in VFI Toolkit. You just use the same as the basic setup, but you specify that you want to solve the general eqm condition that relates to ‘bequest received equals bequests left’ as being ‘by permanent type’ [set heteroagentoptions.GEptype, see WorkshopOLGModel3 for an example], note this requires the BequestRec parameter to differ by permanent type.
Obviously you can combine the ‘by permanent type’ approach with either of the other two described (age dependent vector to control which ages receive bequests; markov to make bequest something you get once and possibly of uncertain size).
What will these do to runtimes? The ‘age dependent parameter’ to control the ages you get bequests is essentially computationally costless. The markov for bequests at an uncertain time is costly, as it adds a markov, but is easy to do and the cost is not too high; the extension of this to uncertain size of bequest is cheaper as going from 3 states to 5 is much cheaper computationally than adding a new dimension with 3 states. Making the bequests ‘conditional on permanent type’ makes no difference to the runtime of the value fn, but slows down the general eqm; it is intermediate difficulty in terms of computation, and because it is just a heteroagentoption is it trivial to implement.
I am not sure if the literature has tried out most of these to see which one works best. If anyone knows and wants to post a reply please do.
PS. The other main alternative to avoid ‘leaking’ assets is to use annuities (scale up the return to assets to redistribute the assets of the deceased).
PPS. In a warm glow you do not directly care for the person receiving the bequest (you just get a warm glow, not something based on the utility of the person receiving the bequest). If you make the parent directly care for the child then this will generate a dynastic OLG, or if the parent and child are not perfectly aligned you get a dynamic game. These can be interesting, but are a substantial complication of the model, so unlikely to be worthwhile unless bequests and intergenerational transmission are the main point of your work.