inet-complexity / housing-model Goto Github PK

@danftang

In order to decide whether or not the buy an additional house, an Investor agent needs to compute its expected rental income (over the next year). Later, if Investor purchased the additional house, the Investor must decide what rent to charge before putting house on the rental market.

The current implementation assumes that, when deciding whether or not to buy the additional house, the Investor expects to receive some markup over its expected mortgage payment as rent payments. Later when deciding what rent to charge it sets rent to be the same markup over mortgage payments. This process seems to be leading to Investor bankruptcies as investors are consistently over estimating rental income.

I propose the following: separate the rule used to forecast expected rental income from the rule used to determine actual rent.

• When considering whether or not to purchase an additional house, forecast expected rental income from that house using an extrapolative rule similar to the following:

future_rental_income = lambda * average_rental_income + (1 - lambda) * old_average_rental_income

• When setting actual rent continue to use the same "markup" over mortgage payment formula.

If large numbers of rental properties are going vacant this will sharply pull down average rental income which, via the above formula, would reduce expected rental income for a new investor. This reduction in expected rental income (all else equal) would reduce the probability of a new investor purchasing an additional property.

Thoughts?

For system size 40000, command line output looks like:

Simulation: 1, time: 2100
Strange: got endOfLettingAgreement on house on rental market
Simulation: 1, time: 2200
Strange: tenant moving into an occupied house
Strange: got endOfLettingAgreement on house on rental market
Simulation: 1, time: 2300
Strange: tenant moving into an occupied house
...It's a homeowner!
Simulation: 1, time: 2400
Simulation: 1, time: 2500
Strange: tenant moving into an occupied house
Strange: tenant moving into an occupied house
Strange: tenant moving into an occupied house

@adrian-carro I am noticing quite a bit of "dead code" that has been commented out but not deleted. Can you please go through and delete this code? I would do it myself, but I worry that I may inadvertently delete something that you might really have needed.

We need to add algorithms for handling two different types of default:

1. Simple default "Exception"
2. Strategic default

Council on Mortgage Lenders (CML) seems like a good place to start for rules and regulations with respect to mortgage default.

Random numbers change from run to run with the same seed!

Variable housing supply is extremely important determinant of long-run housing dynamics. Implementing variable housing supply would require, at a minimum adding the following elements:

1. A construction sector
2. Lending between banks and real estate developers

Currently all Household agents use the same rules (with the same coefficients!) when forming expectations of variables like house price appreciation. We should consider, at a minimum, having heterogeneous coefficients for the expectations formation rules.

Currently all home mortgages are fixed rate mortgages. Most UK mortgages are not fixed rate see Wikipedia entrie on the mortgage industry in the United Kingdom and UK mortgage terminology for some high level details.

Preferably, put them in an input file (like a JSON string) and read them in.

Suggested by John M. A bit uncertain as to what is mean by this. Home equity mortgages perhaps?

Current we assume that Household agents who own "buy to let" properties set rent to be a markup over their mortgage payment. This is unreasonable for (at least) two reasons:

1. most UK mortgages are not fixed rate mortgages and a Household can not "pass on" 100% of the increase in its mortgage payment to its tenant.
2. Household never lowers the rent if its property remains empty (because rent was unaffordable).

Do we really need both, with their respective parameters? Check if any modification of the paper is needed.

Different calculations by buy-to-let households might take or not into account the expected occupancy of their owned or to buy rental properties. Consistency must be enforced, whether in the sense of removing expected occupancy from all calculations or by considering it in all relevant decisions. Modify paper accordingly.

This should include:

1. Central Bank LTI limits should be updated to the current 4.5, 15% over, thus differing from the private bank policy.
2. Computation of the fraction of mortgages over the LTI limit should be made on a 4 quarters rolling basis, as the current policy states, not every month, as currently coded.
3. Stressed interest rates for ICR calculations should be updated according to current values (see here)

Check if paper will need updating after changing this. Currently, this is a flow average, which only takes into account properties sold during this time step. As a consequence, it has a spike whenever the number of sales goes up after a period of low sales. This is not a good way of measuring the average days on the market, as this quantity was growing all along and it actually starts dropping when the market becomes more active. It should thus be replaced by a stock average, taking into account all properties currently offered, not only those sold.

This hack is currently preventing BTL investors from bidding amounts larger than a 10% over the average price of the top quality. Check if paper needs updating

@danftang

Based on feedback from BoE I will remove the income to value (ITV) constraint from the model. Will submit the PR shortly.

@adrian-carro I would recommend using a config library rather than re-inventing the wheel with the current Config class. I have used HOCON in my previous Java/Scala work and it seems solid.

Once I finish PR #38, I will open a PR that swaps out the current Config class for one that uses the HOCON configuration library instead.

Better checking is needed, as constraint is often unmet under certain parameter values and/or when turning off some of the model mechanisms (which shouldn't affect this constraint). Failure to fulfil this constraint is due to rounding errors.

Need to implement life cycle dynamics for households. Life-cycle likely important determinant of longer-run house price dynamics.

Currently we are assuming that all Household agents use the following rule to determine the desired down payment on a mortgage:

public double desiredDownPayment() {
    return GAMMA * bankDeposits + epsilon
}

where 0 < GAMMA < 1 is the faction of bank balances devoted to the down payment is assumed to be common across Households and epsilon is a random term that introduces heterogeneity. Note that the rule used to specify the down payment enters into the house bid price rule (see issue #20).

We need to develop a discrete choice problem that models the decision by a Household that owns one or more houses to sell a house on the market.

For Household that is an owner-occupier decision of when to sell its house will be related to life-cycle factors such as marriage, growing family, kids leaving house, etc. See issue #7 for more details on household life-cycle.

Sale of house by Household agents that own investment properties will likely be based on more "economic" factors. At the moment we have Household agents purchasing investment properties and them holding on the them even as they go bankrupt!

Currently the model does not allow Investor agents to sell properties that turn out to be less than profitable investment opportunities. Simplest way to accommodate this would be to extend the Investor discrete choice problem to include the option to sell one of the houses with some probability.

Variable names in the code should match the variable names in the write up.

Remove parameter and mechanism, i.e., remove the wrong equation for yield calculation keeping only the correct one. Paper needs to be updated as well!

File not used, unclear what's there or where it comes from.

Parameter RETURN_ON_FINANCIAL_WEALTH seems to be an annual interest rate on bank deposits, however, it is computed as a monthly return at getMonthlyGrossTotalIncome(), within the Household class. This needs clarification and, possibly, solving.

Suppose that a Household bids £1000 in rent, but landlord wants £1001. Currently a Household would refuse rental accommodation and remain "homeless." Clearly this is unreasonable behavior on the part of Households (and landlords).

Again we would like to model this as a discrete choice problem: household receives a rental offer which it probabilistically accepts.

@rafabap we need to re-license this repo to use Apache 2.0 instead of MIT license for consistency sake.

Currently, only a direct cash injection to avoid any arrears is implemented, not even terminating outstanding contracts, and the household is left with a bank balance of £1.

We should add old and new UK government policy on stamp duty.

@danftang

I think that income tax bands used to compute income tax liability are incorrect. Current bands are

static final double [] TAX_BANDS = {9440, 9440+32010, 9440+150000};

which I think would be correct if tax liability was being computed on income prior to taking any personal allowance. But since we are computing taxes on taxable income (i.e., total income less any personal allowance), I believe that the bands should be

static final double [] TAX_BANDS = {0, 32010, 150000};

Do you concur?

Quoting @danftang via email...

HPA is computed in the HousingMarket class. It's stored in the HPIAppreciation variable (which actually stores monthly HPA, averaged with an exponentially decaying window of 1 year decay constant - so is roughly 1/12 of the annual HPA). The update is done at the beginning of the clearMarket() method, which is called once per simulated month.

The mechanism is perhaps a little opaque in order to save having to store the house price index history. At the end of month 'n', the HPA for that month is defined as

HPA_n = HPI_n - HPI_{n-1}

The exponentially averaged HPA is defined as

\bar{HPA}n = F*\bar{HPA}{n-1} + (1-F)*HPA_n

so substituting the first into the second equation we have

\bar{HPA}n = F*\bar{HPA}{n-1} + (1-F)*(HPI_n - HPI_{n-1})

In the code, I split this equation into two parts in order to save having to use temporary storage:

1. \bar{HPA} = F_\bar{HPA} - (1-F)_HPI
2. update HPI
3. \bar{HPA} = \bar{HPA} + (1-F)*HPI

We need a separate RentalContract class in order to distinguish such contracts from FixedRateMortgages.

Number of actual sales is far below the number of possible sales, taking into account the number of buyers and sellers coming to the market and the average bid and offer prices. Check if it is a matter of the actual distributions of bid and offer prices having only a small overlap or rather due to the number of clearing rounds not being enough.

We need to consider other rules for forming the house bid price. Currently we have implemented the rule from Axtell et al (2014), but given the import of this rule to the results it would behoove us to consider alternatives.

Possible alternative

Suppose that household wants its monthly mortgage payment to be less than some fraction, PSI, of its monthly disposable income. With fixed rate mortgages this would result in the following implementation:

double interestFactor = (monthlyInterestRate / 
    (1 - Math.pow(1 + monthlyInterestRate, -numberMonthlyPayment)));
double houseBidPrice = desiredDownPayment() + PSI * (monthlyDisposableIncome / interestFactor);

DECISION_TO_SELL_ALPHA, DECISION_TO_SELL_BETA, DECISION_TO_SELL_HPC, DECISION_TO_SELL_INTEREST are earmarked for removal. Check code stability before removing. Modify article accordingly.

Suppose a Household requests a mortgage for £500,000 only to be told by the bank that they can only have a mortgage for £499,999. Currently Household would not accept the mortgage and would continue renting. This is clearly unreasonable behavior.

We should model this decision as a discrete choice problem: Household requests mortgage, Bank either accepts or rejects initial mortgage. If Bank rejects, then Bank makes counter-proposal which Household probabilistically accepts or rejects.

@EconomicSL/core-devs What is the standard tool stack for building Java projects? Is Maven the most widely used standard? What about Gradle, I have zero experience to draw from but I have an allergic reaction to XML and would prefer build scripts that are human readable.

Ideally all of our repos should be built using the same build tool which means the tool needs to be able to compile both Java and Scala. I am pretty sure that Maven and Gradle are capable of doing this...

@adrian-carro Now that the project follows Maven conventions we can start thinking about how to reorganize the packages within the model itself. Do we envision this model eventually becoming a housing module within ESL? If so, then we should use the reverse domain name convention and put everything inside a org.economicsl.housing package.

Within that housing package I think we need to have the following sub-packages

financial
household
government

Organizing principle would be to organize the sub-packages around economic "sectors." Does seem reasonable? What sectors am I missing?

We should extend the behavior of the government agent by implementing housing benefits. I suspect that UK housing benefit plays an important role in UK housing market dynamics. Housing benefits are more complicated then income taxes and national insurance taxes. Place to start reading on housing benefits is gov.uk page on housing benefit

Household agents have two vehicles for saving/investment: bank account (which is a proxy for all financial assets!) and a house. These two asset classes have different returns and a Household agent should take the return differential into account when choosing whether or not to buy a house or rent.

Currently only used to increase bank balances but not in any other decision by the households, which seems incoherent. The decision is to remove the mechanism altogether, in order to remove an unjustified parameter and simplify model and calibration. ** Modify paper accordingly**.

@adrian-carro We need to reorganize this source code so that it follows standard Java Maven project conventions.

Current mortgage interest rate is exogenous and fixed. Having a fixed mortgage interest rate is probably OK for short run issues, but any research into long run housing market dynamics requires a variable mortgage rate.

A reasonable bank would set the mortgage rate to be some markup over its marginal funding cost. Thus to endogenize the mortgage interest rate we need to model how mortgages are actually funded.

@rafabap and @adrian-carro Is this repo being actively developed? If so, then I would like to start integrating the repo into the continuous integration infrastructure that I am developing.