There is a special type of mortgage in the Netherlands (Bank Savings Mortgage or bankspaarhypotheek in Dutch), which I presume, does not exist anywhere else in the world. The construct is that you have a mortgage on your house for a certain amount, say 200000 €, and split it up into two parts:
- one part with a loan (in this case 200000), where you pay only interest
- a second part which is a savings account.
Usually both of these accounts have the same interest rates and you pay a fixed amount per year so that in the end the savings account can be used to pay off the loan. For the bank, this construct is exactly identical to having just one account with a loan that is paid off like an annuitary mortgage with a fixed amount per month.
The difference is in the way this type of mortgage is taxed. On the loan part, the interest is tax deductable, and the savings account is not taxed at all. Therefore in comparison with an annuitary mortgage, where the loan gets less over time (it is equivalent before taxes), there is more tax deduction. And this is what makes it an attractive type of mortgage.
With this type of mortage it is possible to pay off parts of the loan part or to add extra money to the savings account. When given a choice, adding a given amount to the savings account is a lot more attractive than using it to pay off the mortgage. Even though it is equivalent to the bank, putting it into the savings account leads to a higher tax deduction.
But of course, the government has put forward some rules to prevent people from profiting too much, and these make it challenging to determine an optimal scheme to pay of the mortgage to minimize total payments made. For this purpose, this post examines a simple Mixed Linear Integer Program (MILP).
To start with, there are rules for how long the mortgage should be run (the banks also don’t make any money if people pay off their mortgage too soon). In addition, there is the infamous bandwidth rule, which states that for each mortgage year, the maximum amount saved in the savings account should be less than 10 times the minimum amount saved in a mortgage year. If your mortgage started in February, then each mortgage year runs from the start of February of one year to the end of January of the next year.
This bandwidth rule has some interesting implications. Suppose for instance that, initially, you have mandatory payments for the savings account of 200 per month or 2400 per year. Then, in year 2, you pay an additional amount of 10000 which causes the total payment to go to say 12000 (not 12400 since because of the payment, the monthly amount after the payment in the second year goes down immediately). Then in year 3, because of the extra payment, you only pay 1200 per year. Then, in this case the bandwidth limit of 10 () is already reached. As a result of this it is impossible to make any more additional payments into the savings account since that would exceed the bandwidth limit. In this case, it may make more sense to make a lower payment of say 3000 in the second year, and then gradually increase, making sure not to exceed the bandwidth.
In the above example, even without making additional payments, the bandwidth could be also be exceeded if the interest rate on the mortage increases. This is why banks in general enforce a lower bandwidth of say 7 or 8. This makes this mortgage less predictable and a bit risky, except if you fix the interest rate for the entire duration of the mortgage.
As can be seen in the example, it can be quite complex to determine an optimal scheme for additional payments, since there are so many things to consider. Fortunately, this problem can be quite easily formulated as a MILP.
First we define a number of variables to model the savings account:
Here, is the month number.
In addition, there is a restriction from the bank that when a payment is made, the payment must be at least a given amount (say 500). To model this we need a binary variable that indicates whether or not a payment was made:
In addition we introduce some variables into the model for the costs that are convenient to let the model compute the quantities that we are interested in. Instead of having to compute them ourselves afterwards. These are , , and for fixed payments, additional payments, and total payments respectively, where of course .
We define the following input parameters:
Therefore for , , and . For the value is also used since that represents the savings account at the end of the mortgage period.
In the model, we assume that the interest rate is constant, although it is very easy to adapt this to a changing interest rate. Also, because we include the initial amount and the current minimum and maximum saved amounts and so far, it is possible to also model a mortgage starting midway.
To start with we have the initial and terminating conditions:
In addition, we have to define the history of additional payments in the model. For instance, if a mortgage year starts in February, and it is October now, then the additional payments for February through to September must be included. This involves setting for months without payments and setting to non zero values for those months where additional payments were made.
Next we model that the saving account increases due to interest, fixed payments, and additional payments.
For each next month the fixed amount is computed by assuming fixed payments as follows
The minimum payment is modeled using the variable:
Clearly, if , then and otherwise, thereby modeling the minimum payment rule.
Next are the bandwidth requirements. First we define the bandwidth variables:
and then we have the bandwidth restriction
Finally, we define the cost variables:
and the minimization problem
The code is written in R and uses the lpSolve package or gurobi if present. The model appears quite easy since both solvers can solve this problem within a fraction of a second.
There are two files:
- banksparen.R: which is the file that defines the parameters and the model.
- LPModel.R: A R6 utitlity class for defining MILP problems in general. It uses lpSolve or gurobi to solve the MILP problem.
The output from running the model with the example parameters is as follows
> extraPaymentsDf = extraPaymentsDf %>% + filter(extraPayment > 0) > extraPaymentsDf # A tibble: 4 x 5 year month extraPayment fixedPaymentBefore fixedPaymentAfter 1 2019 4 5000 259 223 2 2020 2 5550 223 183 3 2021 2 6099 183 137 4 2022 2 5566 137 93 > > > extraPaymentsFuture = sum(solutione[timeIndex(curYear, curMonth):length(solutione)]) > fixedPaymentsFuture = sum(solutionv[timeIndex(curYear, curMonth):length(solutione)]) > > cat('Total extra payments in the future: ', extraPaymentsFuture, '\n') Total extra payments in the future: 17215.16 > cat('Total fixed payments in the future: ', fixedPaymentsFuture, '\n') Total fixed payments in the future: 21543.87 > cat('Total payments in the future : ', solutioncosts, '\n') Total payments in the future : 45651.6
The output correctly shows the payment that was made in April 2019 and shows three payments to be done at the start of mortgage years 2020, 2021, and 2022 respectively. It also shows the monthly fixed amount before and after the payment. This information is also useful to verify the computation. In my case (different parameter values!), the monthly amounts get within 1 EUR of what I am actually paying. By experimenting with the model, it also becomes easy to see what the effect would be of smaller and larger payments on the total amount paid and on the monthly payments. This makes it a very nice tool to experiment with.