A MICROCOMPUTER/CALCULATOR BASED SOLUTION TO THE CALCULATION OF APR

A MICROCOMPUTER/CALCULATOR BASED SOLUTION TO THE CALCULATION OF APR

Introduction

1. Annexe 1 to the Office of Fair Trading's booklet "Credit Charges and APR" explains the concepts behind the present value method of calculating APR. This paper considers in detail the process of calculating an APR, including the mathematics involved.

2. The only generally applicable method of calculating an APR is to apply the formula and method laid down in Regulation 9 of the Consumer Credit (Total Charge for Credit) Regulations 1980. It usually requires a great deal of calculation to work out an APR using this method - so much so that in most cases carrying out a calculation 'by hand' (eg using an ordinary scientific calculator or logarithms) would be prohibitively time-consuming. This means it's usually necessary to use something like a computer or one of the more advanced programmable calculators to provide a generally applicable method of working out APRs.

[Note: with the introduction of the April 2000 amendments to the Total Charge for Credit Regulations, the only method of calculating an APR provided is the equation now laid down in Regulation 7. Much of the material in this paper pre-dates the latest amendments and some other references to them may also have altered. However, the Regulation 7 equation is a re-statement of the old Regulation 9 formula and method, and the underlying mathematical problem it poses remains the same, so the contents of this paper are still relevant - April 2000.]

3. Even where a computer or calculator is used, calculations can take a considerable amount of time if the approach adopted is not reasonably efficient. The approach described in this paper combines a very powerful method of equation-solving with a program structure which is simple enough to be implemented on the less sophisticated machines (such as programmable calculators) but versatile enough to deal with a wide range of credit agreements.

Symbols and Terms used in this Paper

4. In this paper, unless otherwise stated, these symbols have the following meanings:-

Note: generally the term 'payment' is used to refer to either an advance of credit by the lender to the borrower or one of the borrower's repayments, but 'repayment' refers only to a payment made by the borrower.

5. The mathematics described in this paper requires a basic understanding of algebra, some knowledge of calculus would also be helpful. For those whose maths are a little rusty some 'memory joggers' on mathematical rules have been included. Where necessary, these use the symbols a, b and c, which have no particular meaning.

The Polynomial Problem

6. The biggest single hurdle we face in calculating an APR is that, in the case of any agreement where there's more than one repayment of credit or charges (or more than one advance of credit), the formula given in Regulation 7 of the Total Charge Regulations and the procedure to be followed to apply the formula creates something which mathematicians call a 'polynomial'. In simple terms, a polynomial is a formula or equation in which the thing you're trying to find is raised to several different powers. For example, if you are trying to calculate c ...

... is a polynomial in c.

7. Polynomials like this can't be rearranged algebraically to get c on one side of the 'equals' sign and all the quantifiable information on the other. So, there's no direct method of solving such an equation.

8. Take as an example an agreement for £100 repaid by 3 repayments of £60 made after 1, 2 and 4 years respectively. The 'present value rule' in Regulation 7 amounts to the following formula for the present value of a payment ...

... and goes on to state that the APR is the rate at which the sum (ie the total) of the present values "... as at the relevant date ..." of all the repayments is equal to the sum of the present values of all the advances. The present value of the advance in our example is easy to calculate. It's made on the relevant date so t is zero. Anything raised to the power of zero is equal to one (our first memory jogger), so the bottom half of the formula is equal to one for any value of r and the present value of any payment (made by either the lender or the borrower) on the relevant date is its actual amount - in this case £100. Applying the formula to the rest of the payments, we end up with the following equation from which we have to find r ...

... which contains terms in r to the first power (equivalent to just r), r squared and r to the fourth power, and so can't be solved directly.

9. The only way around this problem is to keep applying the equation to different values of r until we find the value at which the two sides of the equation are equal. Mathematicians call this an iterative process and it would usually be approached in the way shown in the flow chart in Figure 1 below:-

Simplifying the Calculation

10. It will speed up the calculation considerably if we can simplify the step in box 2. This means finding an easier method of dealing with the types of expressions shown in paragraph 8 above. First we'll try to simplify the present value formula itself.

Time Periods

11. We know that it's more common for repayments to be made months or weeks apart rather than years apart. So, it would be more convenient to express the times of the payments (t) in those time periods rather than years. But, because our formula produces an annual rate and expresses t in years, we'll have to use t/m in place of t, where m is the number of time periods in a year. For example, if we want to express t in months, m=12 and a payment made after, say,

3 months is made after 3/12 years. So this gives us the following formula ...

... which is actually slightly more complex than our original one.

Note: in practice m can have any positive value, it can even be less than one if the payments are made less often than annually (eg with payments every 3 years m would be 1/3 because there is a third of a time period in a year).

However, the provisions of Regulation 11 of the Total Charge for Credit Regulations, which deal with the computation of time, should be borne in mind. These require us to express periods in days, weeks, months or years and specify that a day is 1/365th of a year, a month is 1/12th of a year and a week is 1/52nd of a year — so m should only have values of 1, 12, 52, or 365.

[Note: with the revised April 2000 version of the Regulations, days can be expressed in two ways - either all as 1/365.25th of a year, or when dealing with leap years, 1/365th of a normal year and 1/366th of a leap year - so m can now have values of 1, 12, 52, 365.25 or 365 and 366 - April 2000.]

The Intermediate Variable

12. It would be much easier to deal with the calculation if we could express the present value of a payment in terms of just its amount, its time and some other factor (an intermediate variable, which we'll call x), ie something like ...

... so we need to find this x in the following equation ...

... dividing both sides by A ...

... which, using the rule: 1/a^b = a^-b, can be rewritten in the form ...

... cancelling out the power of t on both sides ...

... which, using the rule mentioned above again, can be re-written in the form ...

... applying this rule twice is probably a little long-winded but makes it clear that we can simply cancel out t after dividing both sides by A - even though the right-hand one is on the bottom half of a fraction.

13. This now puts us in a position to carry out the procedure described in Figure 1 by calculating the sum of the present values using formula (1) above and searching for the value of x at which the sum of the present values is equal to the amount loaned (ie box 4 in Figure 1 would now read "Adjust x"). Once we've found the right value of x, we can use it in the above equation to calculate the APR. To do this we need to rearrange the equation so that r is on the left-hand side. Turning the whole equation 'up-side down' gives us ...

... raising both sides to the power of m (a^1/b is the 'bth root' of 'a') ...

... equation (2) can now be used to convert 'x' to an APR.

Regular Payments

14. Fortunately, credit agreements often have equal instalments (as defined in the Consumer Credit Tables) - ie a pattern of repayments, all of the same amount, made at regular weekly, monthly, etc intervals. We can exploit this to introduce a further substantial short-cut.

15. Take an agreement for a loan repaid by n regular payments of £A made after 1, 2, 3, and so on, time periods. Using formula (1), the expression for the sum of the present values (which we'll call S) will be ...

... multiplying both sides of (3) by x gives us ...

... since (3) and (4) are simultaneous equations (in other words S, A, x and n represent the same things in both of them) we can subtract (3) from (4). The underlined terms on the right-hand side of (3) and (4) are the same, so when subtracted from one another they'll cancel out, leaving just Ax¹ (which can be rewritten as Ax) and Axⁿ⁺¹, however many terms there are between the first and last ...

16. This is a very important result because it means that (5) can be used to calculate the total of the present values of any number of regular payments in one step. For example, if we have an agreement like a 25-year mortgage with 300 regular repayments, we can apply (5) once rather than having to use formula (1) 300 times. As you can imagine, this saves an enormous amount of time and effort.

Levels of Repayments

17. This idea of dealing with a number of regular payments in one step can be taken a stage further to make it even more useful.

18. Take an agreement for a loan of £100 which is repaid by 24 monthly instalments, the first 18 of £5 and the last six of £5.75. We can describe the repayment pattern with the diagram in Figure 2 below. Each cross on the diagram represents the amount and time of a repayment. For reasons which are obvious from this diagram, I usually describe such a payment pattern as having two levels.

19. We can't apply equation (5) to this pattern of repayments because they're not all the same amount and we only have one repayment amount, A, in the equation. We can however use (5) to deal with the first 18 repayments because they fall into the pattern described in paragraph 15 above.

20. Unfortunately, the final six repayments are not in the right pattern. If we were to apply (5) with A=£5.75 and n=6 it would calculate the present values as though the repayments were made at times 1 to 6, not 19 to 24. If we try to use (5) with A=£5.75 and n=24 it will calculate the present values of all 24 payments of £5.75 made at times 1 to 24, rather than just the last six.

Amount
    (£)
     ^
     |
5.75 |                  ++++++
5.00 |++++++++++++++++++
     |
     |
     |
     |
     +------------------------->
   0                             time
      1    6    12    18    24 (months)

               (Figure 2)

21. We could use formula (1) to calculate the present values of the last six payments individually, but if there were 60 of them rather than six we'd be back where we started, performing a large number of individual calculations.

22. However, there's a way around this. Look at the diagram in Figure 3. We need to be able to calculate the sum of the present values of the repayments represented by the crosses. We can already calculate the present values of all these payments from 1 to e (for "end") - ie both the noughts and the crosses - by applying equation (5) with n = e. Also we can calculate the present values of the payments from 1 to b (for "beginning") - ie just the noughts - by applying (5) with n = b ...

Amount
    (£)
     ^
     |
   A |oooooooooooo++++++++++++
     |           .           .
     |           .           .
     |           .           .
     |           .           .
     |           .           .
     +-------------------------> time
    0                             (in time
      1          b           e     periods)

             (Figure 3)

... so, the present values of the crosses (which we'll call S_lev) can be calculated by subtracting the sum for the noughts from the sum for the noughts and crosses ...

... multiplying out the brackets and combining the terms ...

... equation (6) will calculate the sum of the present values of a level of repayments of amount A beginning at time b and ending at time e for a given value of x.

23. At this point I should introduce a formal definition of the term level:-

A "level" is a series of repayments of the same amount made at regular intervals, one each time period. The first repayment in a level occurs one time period after the level begins.

Point to note (1)

24. The idea that the first repayment occurs one time period after the beginning of the level may seem confusing at first but it's used for a number of reasons:-

(a) most importantly, this is the basis on which I have developed equation (6) and it will only give the right answer when used in this way,

(b) it allows us to 'chain together' a number of levels with the same value representing the end point of one level and the beginning of the next. For example, in the case described in Figure 1 above, time point 18 is both the end (e) of the first level and the beginning (b) of the second - a useful space-saver in some small machines.

(c) it can actually avoid some confusion because it means that the number of payments in a level and the length of the level in time periods is the same. If we were to assume a level started with the first payment and ended with the last, there would be one more payment in the level than its length in time periods.

Point to note (2)

25. Because of our chosen method of representing a level, the first level in an agreement is assumed to start at 'time zero' (ie the relevant date) rather than at 'time one'.

Point to note (3)

26. Equation (6) works for non-integer values of b and e. For example, (6) will correctly calculate the sum of the present values of a level of 7 monthly repayments which starts 3.2 months after the relevant date and ends at 10.2 months. However, the constraints of Regulation 11 of the Total Charge for Credit Regulations ("Computation of time") require us to calculate periods which are not whole calendar months or weeks in years and days. Since the periods in question (ie those from the relevant date to the date of each repayment in the level) are not whole months, we have to calculate them in years and days. Variations in the number of days in a month mean that there are unequal periods between the repayments in such cases and the method of levels should not be applied.

Irregular or 'Extra' Payments

27. We're not going to be able to describe all repayment patterns just in terms of levels. Often agreements will have a largely regular payment pattern but with an odd repayment at the outset (eg a deposit) or at the end (eg an option to purchase fee under a hire-purchase agreement or a different final payment to make an adjustment for payments which have been rounded to the nearest penny). Inevitably, there will also be some agreements where only a small proportion of the repayments (or even none of them) can be described as levels. I usually refer to repayments of this type as extra payments.

28. In such cases we're forced to resort to the method of calculating the present values of individual repayments separately. Fortunately, since our objective is to calculate the sum (or total) of all the present values, we can calculate the present values of any levels using equation (6), calculate the present values of any extra payments using formula (1), and then add together these results to give the overall total.

Series of Repayments

28A. We may also be faced with cases where there are regular payments in addition to the normal monthly or weekly repayments: for example, an annual administration fee or quarterly insurance premiums paid in addition to regular monthly repayments. I usually refer to such repayments as a series. Although we can't deal with such series using our formula for levels, we may be able to exploit their regularity to reduce the amount of information the user has to enter into a program. In fact, the user need only give the following information to describe the times of all the repayments in a series:-

(1) the time of the first repayment,

(2) the interval between repayments, and

(3) the number of repayments.

28B. The program can calculate the time of each repayment in the series from this information and, assuming they're all the same amount, the user only has to enter that amount once. We can go on to develop a formula to calculate the present values of such a series in much the same way as we have with levels:-

(both f and g being expressed in time periods).

28C. However, it's probably much more useful to extend the series approach to deal with cases where the amount of each repayment is different, or cases such as those described in paragraph 26 where the repayments are one or more calendar months apart but levels can't be used because of the time of the first repayment isn't a whole number of months from the relevant date. In either of these cases the program will have to calculate the sum of each present value individually using formula (1) so we don't generally need a more complex formula.

Further Advances of Credit

29. Occasionally we'll come across agreements where there are several advances of credit made by the lender. The Regulations provide the same formula for the calculation of the present values of all payments whether they are advances or repayments. Consequently, the various formulae described above are equally applicable to both types of payment. In practice, however, it's unusual to meet agreements which have more than two or three advances and it's unlikely that we'll have to deal with levels or series of advances. All advances can therefore normally be dealt with one at a time using the same approach as for extra payments.

Finding the Answer

30. We've now got a reasonably fast and efficient method of carrying out the procedure described in box 2 of Figure 1 for any given value of x (and consequently for any given APR). Having done so and found that our starting value is wrong, ie the answer to the question in box 3 is "No", we have to think about box 4 - which we now read as "Adjust the value of x". Do we make x larger or smaller, and by how much?

31. It's not too difficult to decide whether the value of x should be increased or decreased. Consider the following points:-

if we look at equation 2 (in paragraph 13) we can see that, because it has (1/x) in it, as x gets smaller the APR will get bigger,
we know that, for a given loan amount repaid by a fixed number of repayments at fixed times (eg, £100 repaid by 24 monthly repayments), the larger the repayments required by the agreement, the higher the APR will be.

... so we can reason that if the sum of the present values comes to more than the loan we have chosen too low an APR (effectively this result is telling us that, at our current 'guess' for the APR, the payments will pay off a bigger loan than was actually borrowed), so x needs to be decreased. Conversely, if the sum of the present values is less than the loan, the APR is too high and x must be increased.

32. We can't calculate exactly how much x should be adjusted, essentially because of the same 'polynomial problem'. We're also unlikely to have much luck simply 'hunting around' at random for the right answer: so some form of methodical approach is needed. For example, since an APR is truncated to one decimal place, we could adjust the APR in steps of 0.1 (x could be recalculated using the formula at the end of paragraph 12) until we hit the right answer. However, this method has an obvious drawback: if our first guess at the APR is only, say, 10% out, it will take us 100 goes to find the right answer. Some computer programs I've seen adopt a more efficient version of this by adjusting the APR in steps of ten until it gets as close as possible, then switching to adjusting in steps of one and, when that gets as close as it can, finally adjusting it by 0.1. But this is still not very efficient in many cases (eg it might work well if the APR happens to be, say 20, but not if it's 11.9).

The Present Value Function

33. Although we've found a short-cut to calculating its value, we're actually dealing with a very complex mathematical equation (equation (3) is a fairly simple example) and need to find the value of x at which the left and right-hand sides are equal or, looked at another way, the value at which the right-hand side minus the left-hand side is equal to zero.

34. Mathematicians often use a form of shorthand to refer to a complex expression equated to zero in this way. It's generally called a function (in this case a 'function of x' since x is what we are trying to find) and is written as just f(x) (usually pronounced "F of X").

35. Figure 4 shows the graphs of the present value functions for two loans. In both cases the amount of the loan is £150 and the amount of the repayments is £15. In one case there are 11 repayments and in the other there are 14 (labelled on the graph). Although every agreement will have a slightly different graph they will generally all look something like one of these two. Interestingly, whether the graph goes up or down on the left of the vertical y-axis is controlled by whether the last repayment in the agreement is made an even (for up) or an odd (for down) number of time periods after the relevant date. I'll leave you to think about which is which where they split on the right-hand side - remember, the bigger the APR the smaller the x value.

36. We're looking for the point (or points) at which the value of the function is zero, ie the places where the curve of the graph crosses the horizontal x-axis. Such points are generally referred to as the roots of the function. In one of the graphs we have two roots and, potentially, two APRs. However, Regulation 7(4) of the Total Charge for Credit Regulations solves this problem for us by stating that:-

"Where more than one rate is given under paragraph (1) above, the annual percentage rate of charge is the positive rate nearest to zero or, if no positive rate is so given, the negative rate nearest to zero."

37. Since a positive value of x will, generally, give a positive APR, the root we use is the positive one to the right of the y-axis.

The Bisection Method

38. This method of finding a root is fairly easy to explain. It's very similar to something called 'binary search', or sometimes 'binary chop', used in computing to find an item of information in an ordered list (eg in a database where the items of data are in alphabetical, numerical etc order). In fact you probably automatically use something like it yourself when looking through a phone book or dictionary. Imagine you are looking for a name in alphabetical list with 5,000 names from "Arthur" to "Zaphod". If you start at the beginning and search through the list name by name, it'll take on average 2,500 tries to find the right name (of course, the number of tries would depend on the name you're looking for). But say you're looking for "Jenkins" using a binary search. You start by looking half way down the list and find, say, "Nixon". This is too far down the list so you discard everything from "Nixon" to "Zaphod" - ie half the list. Then you look again half way between "Arthur" and "Nixon" giving, say, "Gifford". This name comes too early in the list so you ignore everything before "Gifford", halving the list again. Now you check a third time half way between "Gifford" and "Nixon" ... and so on. You continue this, halving the list each time, until only "Jenkins" is left. The binary search method should always find the right name after only 12 or 13 tries. Why so few? Because that's the maximum number of times you can halve the 5,000 names in the list before being left with just one. And, because you're halving the list with every try, it would only take one more try to check a list of 10,000 names.

39. The bisection method can be used in much the same way to find our root of the present value function. We know from graphs such as those in Figure 4 that the value of x we're interested in is somewhere between zero and one (in fact it is usually between 0.5 and one but to play safe we'll check the whole range). So we start with a minimum value for our search range of zero and a maximum value of one. The first value of x used is half way between the two, 0.5.

40. The value of our function (ie the present values of the repayments minus the present values of the advances) is calculated for this value. Depending on whether the result of the calculation is more or less than zero, we then use the reasoning in paragraph 31 above to decide whether to move the upper limit of our search range down to x or move the lower limit up. Our next value of x is then half way between the new limits. Now the procedure is repeated (in a sense, we go back to the beginning of this paragraph). This continues until the size of the range is so small that any discrepancies can be safely ignored. I generally repeat the procedure until the size of the range is less than 0.000000001.

41. The following extract from a computer program, written in BBC BASIC, shows how simple this procedure is to program. When this part of the program is executed, all the necessary information has already been given to the computer. Line 230 sets the initial limits of our search range; line 250 calculates the corresponding mid-point value for x; line 260 calculates f(x) (called just 'fx' in the program) based on the amount ('pay') and number ('num') of payments and the value of x. This is done using a function 'FNpv'. Because we're concentrating on the search method here I haven't listed the function, but it's just equation (5) translated into BASIC. Finally, line 270 decides which of the limits should be moved, based on the value of f(x). Lines 240 and 280 control the repetition of this sequence of events until the size of the range is less than 0.000000001 (ie 1 x 10^-9 or 1E-9 in BASIC).

220 :
230 lox=0:hix=1
240 REPEAT
250   x=lox+(hix-lox)/2
260   fx=FNpv(pay,num,x)-loan
270   IF fx > 0 THEN hix=x ELSE lox=x
280   UNTIL hix-lox < 1E-9
290 :

42. Figure 5 shows a table of the results for this procedure. This particular calculation is for the second example in paragraph 35 (ie a loan of £150 repaid by 14 instalments of £15). You can see that, although f(x) has been reduced to a fraction of a penny after 18 tries, the procedure is carried out 30 times in all to refine the value of x to nine decimal places. This gives us a very precise result. The number of iterations taken is determined by the precision to which x is calculated rather than the details of the agreement under consideration.

+-----+---------------------------+-------------+---------+
|     |        Search Range       |             |         |
| Try +-------------+-------------+   Current   |   f(x)  |
| No. |    From     |     To      |  value of x |         |
+-----+-------------+-------------+-------------+---------+
|   1 | 0.000000000 | 1.000000000 | 0.500000000 | 135.00- |
|   2 | 0.500000000 | 1.000000000 | 0.750000000 | 105.80- |
|   3 | 0.750000000 | 1.000000000 | 0.875000000 |  61.19- |
|   4 | 0.875000000 | 1.000000000 | 0.937500000 |  16.16- |
|   5 | 0.937500000 | 1.000000000 | 0.968750000 |  16.86+ |
|   6 | 0.937500000 | 0.968750000 | 0.953125000 |   0.74- |
|   7 | 0.953125000 | 0.968750000 | 0.960937500 |   7.77+ |
|   8 | 0.953125000 | 0.960937500 | 0.957031250 |   3.44+ |
|   9 | 0.953125000 | 0.957031250 | 0.955078125 |   1.34+ |
|  10 | 0.953125000 | 0.955078125 | 0.954101562 |   0.29+ |
|  11 | 0.953125000 | 0.954101562 | 0.953613281 |   0.22- |
|  12 | 0.953613281 | 0.954101562 | 0.953857422 |   0.03+ |
|  13 | 0.953613281 | 0.953857422 | 0.953735352 |   0.09- |
|  14 | 0.953735352 | 0.953857422 | 0.953796387 |   0.03- |
|  15 | 0.953796387 | 0.953857422 | 0.953826904 |   0.00+ |
|  16 | 0.953796387 | 0.953826904 | 0.953811646 |   0.01- |
|  17 | 0.953811646 | 0.953826904 | 0.953819275 |   0.01- |
|  18 | 0.953819275 | 0.953826904 | 0.953823090 |   0.00- |
|  19 | 0.953823090 | 0.953826904 | 0.953824997 |   0.00+ |
|  20 | 0.953823090 | 0.953824997 | 0.953824043 |   0.00- |
|  21 | 0.953824043 | 0.953824997 | 0.953824520 |   0.00- |
|  22 | 0.953824520 | 0.953824997 | 0.953824759 |   0.00+ |
|  23 | 0.953824520 | 0.953824759 | 0.953824639 |   0.00- |
|  24 | 0.953824639 | 0.953824759 | 0.953824699 |   0.00- |
|  25 | 0.953824699 | 0.953824759 | 0.953824729 |   0.00+ |
|  26 | 0.953824699 | 0.953824729 | 0.953824714 |   0.00- |
|  27 | 0.953824714 | 0.953824729 | 0.953824721 |   0.00- |
|  28 | 0.953824721 | 0.953824729 | 0.953824725 |   0.00- |
|  29 | 0.953824725 | 0.953824729 | 0.953824727 |   0.00- |
|  30 | 0.953824727 | 0.953824729 | 0.953824728 |   0.00- |
+-----+-------------+-------------+-------------+---------+

(Figure 5)

The Newton-Rapheson Method of Successive Approximations

43. This is a more powerful method of finding roots using calculus and is sometimes also known as just 'Newton's Method'. Unfortunately, it's more difficult to explain how this method operates, and we'll have to develop and use some additional, quite complex formulae before we can apply it to our APR calculations. In its favour, Newton's method is surprisingly powerful and can often find the roots of an equation to a high degree of accuracy in only four or five goes.

44. Look at Figure 6, which is an enlargement of one of the functions in Figure 4 in the region of the right-hand root. We'll use the notation aB to refer to the line between points a and B in the diagram and also to its length. The lines aB, bC and cR (too close to the curve to see easily) are tangents to the curve at points a, b and c. The dotted lines Aa, Bb and Cc are vertical projections from the x-axis. R marks the root we're trying to find.

45. You can see that following the zig-zag path A, a, B, b, C, c, and so on, very quickly brings us to R. This is exactly what Newton's method does. A represents our starting value of x. The next value of x is calculated by finding the point B at which the tangent to the curve at a (vertically above A) cuts the x-axis. This procedure is repeated until the difference between the new and old values of x is sufficiently small to be ignored (we will use 1E-9 again). This works equally well either side of the root.

46. Calculus provides us with a way to create a formula which will calculate the gradient of the curve of a function at any point. This formula is known as the 'derivative' of the function and is usually written as f'(x) (pronounced "F dashed of X").

47. Just like you'd calculate the slope of a hill, the gradient of the line Ba can be calculated as Aa/BA. The gradient of Ba can also be calculated by f'(x) and, in addition, we know that the length Aa represents the value of f(x) for our current x value and the length BA represents the difference between the new and old values of x. So we can write the following ...

... this is the formula used to apply Newton's method.

A Word of Warning (1)

48. Like most of the more powerful methods for finding the roots of an equation, Newton's method won't work every time. The starting value of x is always critical when applying this method. Look again at Figure 4 and imagine what would happen if, for example, we started the procedure described in paragraph 45 with a value of x close to zero. The tangent to the curve for such a low value of x would only cross the x-axis way off to the right (if at all). For this reason (and because experience in using the method has shown us that it generally produces a result more quickly) we start the calculation with a value of x slightly above one, say 1.001 or 1.0001. This means that the procedure is always forced to hunt downslope for the next approximation of x.

49. This in itself can create a problem. Although unlikely, it's possible that while moving downslope the procedure could produce an x value of exactly one. If it does, the bottom half of equation (6) will be equal to zero. Since dividing anything by zero produces an infinite result this will cause an error in most calculators or computer languages. The simplest solution to this problem is to check the value of x each time it's altered and, if it's one, change it to something else like 0.9999. Because we're using an iterative method this change won't affect the validity of our final result.

Word of Warning (2)

50. It's also possible, although equally unusual, for the method to suffer from 'oscillation'. This means it gets stuck, jumping backwards and forwards either side of the root without getting any closer. This is harder to detect in a program and perhaps the easiest solution is to place a limit on the number of iterations the program will perform - say 50. If this limit is exceeded, the program could start again using a different initial value for x (again, 0.9999) or perhaps switch to the bisection method.

51. It should be stressed that it's fairly uncommon to run into either of these problems. If program space is limited in the particular machine you are using, the 'evasive manoeuvres' mentioned above aren't likely to be essential.

Calculating the Derivatives

52. To apply Newton's method to our problem we need to find the derivatives of the elements that make up our f(x), ie formula (1) and equation (6). The general rule for differentiation (the process of calculating a derivative) is ...

... and the derivatives of any constant values (eg 99 or the amount of the loan) are always zero.

53. This can be applied directly to formula (1) to give ...

... which will calculate the derivative value for any extra payments. The same formula can be used to calculate the derivatives of the individual repayments forming a series - see paragraphs 28A and 28B.

54. Unfortunately, the differentiation of equation (6) is more complicated because of its fractional form. The rule for differentiating a fractional function is ...

... where u and v represent the top and bottom halves of the fraction and u' and v' represent their derivatives.

55. So, in our case ...

... (multiplying out will help later on) and ...

... differentiating the terms of u and v ...

... and (remember a⁰=1) ...

... applying the fraction rule (the dot is shorthand for 'multiply') ...

... multiplying out the terms ...

... similarly ...

... subtracting (11) from (10) the terms raised to the power of e+1 and b+1 cancel partially giving ...

... and to complete the calculation of the derivative ...

... finally, taking A outside the brackets in the top half ...

... formula (12) will calculate the sum of the derivatives of the present values of a level of repayments of amount A beginning at time b and ending at time e.

Derivatives for Alternative Formulae

56. Equation (5) is a simpler version of equation (6) which will deal with a single level which begins on the relevant date. You may wish to note that the corresponding derivative of (5) is:-

... this formula may prove useful in some simpler programs which deal only with equal instalment transactions (as defined in the Consumer Credit Tables).

NOTE: Equation (5) only calculates the present value of the repayments. Our f(x) should also take account of the loan amount and is therefore the right-hand side of (5) minus the loan amount. Since this is a constant, its derivative is zero (see paragraph 52 above) and it doesn't appear in equation (13).

56A. Similarly, the formula for the derivative of equation (7) which deals with a regular series of repayments is:-

57. We now have all the formulae necessary to calculate an APR using Newton's method. The following BBC BASIC extract shows how it can be programmed ...

490 :
500 x=1.0001
510 REPEAT
520   fx=FNpv(pay,num,x)-loan
530   dx=FNdv(pay,num,x)
540   diff=fx/dx
550   x=x-diff
560   UNTIL ABS(diff) < 1E-9
570 :

... as with the earlier program extract, the program already has all the loan details at this stage. Line 500 sets the initial value of x, line 520 calculates f(x) as with the bisection method and line 530 similarly calculates f'(x) (called dx in the program) using a function FNdv defined elsewhere in the program. In this simplified example, formulae (5) and (13) have been used in these functions. Line 540 calculates the difference between the new and old values of x as f(x)/f'(x) - see equation (8) - and 550 adjusts the value of x. Lines 510 and 560 control the repetition of this sequence of events until the absolute value of the difference (ie ignoring whether it is positive or negative as we're only interested in its size, ABS(diff) in BASIC) is less than 0.000000001. Figure 7 shows this procedure in operation on the same loan as that dealt with in Figure 5, as you can see, x is found in considerably fewer iterations than with the bisection method.

+-----+--------------+--------+----------+--------------+
| Try |   Current    |  f(x)  |  f'(x)   |  Adjustment  |
| No. |  value of x  |        |          |     to x     |
+-----+--------------+--------+----------+--------------+
|  1  | 1.000100000  | 60.16+ | 1575.80+ | 0.038175733- |
|  2  | 0.961924267  |  8.88+ | 1135.12+ | 0.007826562- |
|  3  | 0.954097705  |  0.29+ | 1061.99+ | 0.000272661- |
|  4  | 0.953825044  |  0.00+ | 1059.53+ | 0.000000316- |
|  5  | 0.953824728  |  0.00+ | 1059.53+ | 0.000000000- |
+-----+--------------+--------+----------+--------------+
(Figure 7)

Word of Warning (3)

58. Note that word of warning (1) should be repeated here. Since equation (12) and formula (13) have (x-1) in their bottom halves, an x-value of one will generate an infinite result. Also, in some unusual circumstances, our equation for f'(x) will evaluate as zero. Consequently, the calculation of f(x)/f'(x) can also create a 'division by zero' error.

NOTE: this problem was brought to light by a Trading Standards Department using one of the very early versions of the program which didn't start with an x value greater than one. It doesn't appear to happen with later ones.

If this problem should crop up, it's easily dealt with by testing the value of f'(x) before the division is carried out and restarting the calculation with a slightly different x-value where it is zero (see paragraph 49 above for an example).

The BASIC Computer Program

59. The language I've chosen to use is BASIC ("Beginner's All-purpose Symbolic Instruction Code"). After being developed at Dartmouth College, New Hampshire, USA in the mid-60's BASIC grew in both popularity and complexity during the 70's and early 80's. Although it's now less used for professional programming than other languages, particularly C and its variants, it is much more 'human readable' than some of these, versions of it are still widely used for tasks such as programming applications or scripting Web pages - eg Microsoft's Visual Basic for Applications (VBA) and VBScript - and various versions are readily available for download from the Internet.

60. Unfortunately BASIC, like the English language, is a collection of different 'dialects' rather than a single, fixed language. In order to avoid any problems this might cause we'll provide only the minimum code necessary to illustrate the calculation of an APR and use a very restricted subset of the keywords in the BASIC language which is likely to be available in most versions of BASIC.

61. It should be emphasised that, as it stands, the program listed here contains no error-checking. If you give it a nonsensical set of data it will calculate a nonsensical APR (or might crash). A full implementation should ideally contain the following features:-

(1) all inputs should be restricted to an acceptable range and type - eg, the number of advances entered should be a positive integer in the range 1 to, say, 10; all other inputs being rejected. Figure 8 gives further examples.

(2) even where each datum is in itself valid, certain combinations of data will create nonsensical situations. A full implementation should also makes checks for the following conditions:-

(a) the total amount advanced is zero;

(b) there are no levels AND no extra payments (ie no repayments at all);

(d) the total repaid equals the total advanced (this agreement has an APR of zero so there's no need to use the program anyway);

(e) the total repaid is less than the total advanced (this agreement has a negative rate, the program can deal with these cases but the user should be asked for confirmation before continuing).

(3) other features you may wish to consider adding to this 'skeleton' are:-

(a) a visual report of the current progress made by the iteration (this is most easily achieved by printing the value of f(x) after each iteration, the user can then check its progress towards zero);

(b) facilities to review the details the user has input and to print out both the input and results;

(c) a calculator facility to enable the user to perform arithmetic during the course of data entry (most 'pocket computers' and programmable calculators allow this anyway);

(d) a calendar facility to enable the user to enter times in the form of dates or to calculate the length of the period between two dates.

+-------------------+----------+---------+---------+---------+
|     Data Item     | Positive | Integer | Minimum | Maximum |
+-------------------+----------+---------+---------+---------+
| No. of Advances   |     x    |    x    |    1    |    10*  |
| No. of Levels     |     x    |    x    |    0    |    20*  |
| No. of Extras     |     x    |    x    |    0    |   300*  |
|                   |          |         |         |         |
| Loan/Advance (£)  |     x    |         |   >0    |         |
| Loan/Advance time |     x    |         |    0    |         |
| Level (£)         |     x    |         |    0    |         |
| Level length      |     x    |    x    |    1    |         |
| Extra (£)         |     x    |         |   >0    |         |
| Extra time        |     x    |         |    0    |         |
|                   +----------+---------+---------+---------+
| Periods p.a.      |accept only 1, 12, 52, 365.25, 365 & 366|
+-------------------+----------------------------------------+

x indicates 'check for this'
> indicates 'greater than'
* suggested maxima

(Figure 8)

Program Notes and Hints on Conversion

62. The listing given later was written some time ago on a BBC Microcomputer using BBC BASIC Version 2. It will work in most other versions of BBC BASIC (including BBC BASIC for Windows and The Brandy Basic Interpreter for DOS, both of which support the latest version V of BBC BASIC) and also in QBASIC, GWBASIC etc on PCs runnning DOS (but see paragraph 63 below) and should require only minor amendments (or none at all) to work on most other BASIC dialects. Although the listing is short, I have tried to keep to a fairly structured, modular style to make it easier to convert to other languages.

[Note: The April 2000 Regulations changed the method of abbreviating the final APR result from truncation to 1 decimal place (where a result of 10.99999 gives an APR of 10.9) to the more common rounding to one decimal place (where a result of 10.45000 gives an APR of 10.5 and 10.44999 gives an APR of 10.4). The listing below has been changed to reflect this by the insertion of '+.5' in line 390 - April 2000.]

Precision Considerations

63. Some BASIC dialects, including some of those available with PCs, and some compilers for other languages like C store 'reals' (non-integer or floating point values) in only 4 bytes of memory, with inevitable limitations in precision. However they can often be made to store values more precisely, eg in some BASICs by incorporating a "DEF DBL" (define as double-precision) statement at the beginning of the program or by adding a "!" or "#" to the names of the more critical variables (D,F,Q,R,X and Z in our program) - consult your manual for further details.

63A. Unfortunately, presumably to speed up program execution, some languages still calculate 'exponential' functions (ie those concerned with powers etc) to only 4-byte precision, even where double-precision values are involved. There may be no simple way to overcome this hurdle. If double-precision values are used, the resulting degree of error should not normally be enough to make the final, truncated APR inaccurate (any error will probably be in the third or fourth decimal place). However, I recommend that you use an interpreter or compiler which stores reals and calculates exponents to at least 5-byte precision - again, consult your manual for details.

63B. Because of the reduced precision in some languages, the test in line 310 of the program may be too stringent to ever be passed. This will result in the program looping forever. To avoid this the test can be reduced to IF ABS(Z)>1E-7 THEN 250 or IF ABS(Z)>1E-6 THEN 250. However, this will degrade the accuracy of the APR calculated by the program and I would not advise reducing the stringency any further. If the program still loops, unfortunately, you'll have to look to an alternative language (or machine) for your solution.

64. The BASIC Program Listing

10 REM TRURATE 20 : 30 DIM L(10,1),G(20,1),H(50,1) 40 : 50 CLS 60 PRINT "CALCULATION OF APR" 70 PRINT "==================" 80 PRINT 90 : 100 S=0:P=0 110 INPUT "How many Advances ";I 120 INPUT "How many Levels ";J 130 INPUT "How many Extras ";K 140 : 150 GOSUB 1000 160 IF J>0 THEN GOSUB 2000 170 IF K>0 THEN GOSUB 3000 180 : 190 CLS 200 PRINT "PERIODS:" 210 PRINT 220 INPUT "Periods p.a. ";M 230 : 240 X=1.0001 250 F=0:D=0 260 GOSUB 4000 270 IF J>0 THEN GOSUB 5000 280 IF K>0 THEN GOSUB 6000 290 Z=F/D 300 X=X-Z 310 IF ABS(Z)>1E-9 THEN 250 320 : 330 R=100*((1/X)^M-1) 340 CLS 350 PRINT "RESULTS:" 360 PRINT 370 PRINT "TAP = ";P 380 PRINT "TCC = ";P-S 390 PRINT "APR = ";(INT(10*R+.5))/10 400 PRINT 410 END 420 : 1000 CLS 1010 PRINT "ADVANCES:" 1020 PRINT 1030 IF I>1 THEN 1090 1040 INPUT "Loan £ ";L(1,0) 1050 L(1,1)=0 1060 S=L(1,0) 1070 RETURN 1080 : 1090 FOR N=1 TO I 1100 PRINT "Advance ";N; 1110 INPUT " £ ";L(N,0) 1120 INPUT "at time ";L(N,1) 1130 S=S+L(N,0) 1140 NEXT 1150 RETURN 1160 : 2000 CLS 2010 PRINT "LEVELS:" 2020 PRINT 2030 FOR N=1 TO J 2040 PRINT "Level ";N; 2050 INPUT " £ ";G(N,0) 2060 INPUT "length ";G(N,1) 2070 P=P+G(N,0)*G(N,1) 2080 NEXT 2090 RETURN 2100 : 3000 CLS 3010 PRINT "EXTRAS:" 3020 PRINT 3030 FOR N=1 TO K 3040 PRINT "Extra ";N; 3050 INPUT " £ ";H(N,0) 3060 INPUT "at time ";H(N,1) 3070 P=P+H(N,0) 3080 NEXT 3090 RETURN 3100 : 4000 FOR N=1 TO I 4010 A=L(N,0):T=L(N,1) 4020 F=F-A*X^T 4030 D=D-T*A*X^(T-1) 4040 NEXT 4050 RETURN 4060 : 5000 B=0 5010 FOR N=1 TO J 5020 A=G(N,0):E=B+G(N,1) 5030 F=F+A*(X^(E+1)-X^(B+1))/(X-1) 5040 Q=E*X^(E+1)-B*X^(B+1) 5050 Q=Q-(E+1)*X^E+(B+1)*X^B 5060 D=D+A*Q/(X-1)^2 5070 B=E 5080 NEXT 5090 RETURN 5100 : 6000 FOR N=1 TO K 6010 A=H(N,0):T=H(N,1) 6020 F=F+A*X^T 6030 D=D+T*A*X^(T-1) 6040 NEXT 6050 RETURN

Use of Variables

65. The variables used in the program represent the following items of data:-

The Program in Detail

66. The following attempts to explain the operation of the program in detail. If you're familiar with BASIC you may want to skip this section.

(1) Lines containing only colons have been used to break up the listing and highlight the program structure. They have no effect and can be omitted. Loops in the program structure have been indented to make them clearer, the extra spaces can be omitted. The line numbers in the following sections have been underlined to help you to pick them out.

(2) Line 30: DIMensions arrays with sufficient space to store the data for 10 advances, 20 levels and 50 extra payments. Two-dimensional arrays are used to store the two items of data relevant to each advance, level or extra - see paragraph 65 for details. It has been assumed that arrays have a 'zeroth' element, as in most BASICs. If your dialect will only accept one-dimensional arrays, separate arrays can be used for the amount data and the time (or length) data. If, as is the case with some 'pocket computers', only a single, one-dimensional array is permitted, all the payment data can be stored by setting up a pointer to the next free element in the array and increasing it after each item is filed away. Assume, for example, that the array is W() and the pointer is V; we will also use C to transfer data into and out of the array and U to record the sum to be added to the total advanced or repaid. The following routines can be added to the program:-

100 S=0:P=0:V=0 ... 250 F=0:D=0:V=0 ... 6070 : 7000 W(V)=C:V=V+1:RETURN:REM FILE 7010 : 8000 C=W(V):V=V+1:RETURN:REM FETCH

The pointer V should be set to zero at line 100 and again at 250 (ie replace the existing lines as above, adding ":V=0" to both).

Data can then be filed in the array by replacing the existing code with the following:-

1040 INPUT "Loan £ ";U:C=U:GOSUB 7000 1050 C=0:GOSUB 7000 1060 S=U ... 1110 INPUT " ";U:C=U:GOSUB 7000 1120 INPUT "at time ";C:GOSUB 7000 1130 S=S+U ... 2050 INPUT " ";U:C=U:GOSUB 7000 2060 INPUT "Length ";C:GOSUB 7000 2070 P=P+U*C ... 3050 INPUT " ";U:C=U:GOSUB 7000 3060 INPUT "at time ";C:GOSUB 7000 3070 P=P+U ...

NOTE: If (as suggested in paragraph 61 above) you're adding error-checking code to a program using this system, remember that data should be tested - and where necessary re-input - before the subroutine at 7000 is used to file it away in the array, otherwise, the pointer (V) will have been moved on to the next array element.

Data can be fetched from the array with the following ...

4010 GOSUB 8000:A=C:GOSUB 8000:T=C ... 5020 GOSUB 8000:A=C:GOSUB 8000:E=B+C ... 6010 GOSUB 8000:A=C:GOSUB 8000:T=C ...

... and similar methods can be used to implement the program in programmable calculator languages which access a series of numbered memories rather than named variables.

(3) Lines 50 to 80: clear the screen and print a title. If your machine doesn't understand "CLS" (clear screen) try "HOME" or "PRINT CHR$(12);" - consult your manual.

(4) Lines 100 to 130: set the total advanced (S) and the total repaid (P) to zero and then prompt the user for the number of advances (I), levels (J) and extras (K).

(5) Lines 150 to 170: call the subroutine at 1000 to prompt the user for details of the advances (there's always at least one advance). If there are any levels, the subroutine at 2000 is called to prompt for details. Similarly, if there are any extras, the routine at 3000 is called to prompt for their details.

(6) Lines 190 to 220: prompt the user for the number of time periods per annum.

(7) Lines 240 to 310: carry out Newton's method. These are very similar to the code already described in paragraph 57 above. Line 240 sets the initial value of X; 250 resets F and D, which are used to keep running totals of f(x) and f'(x) respectively, to zero at the start of each iteration; 260 calls the subroutine at 4000 which calculates the present values of the advances and their derivatives. If there are any levels, 270 calls the subroutine at 5000 which calculates the present values and the derivatives for the levels; similarly, if there are any extras, the routine at 6000 is called to calculate their present values and derivatives. Line 290 calculates the adjustment to be subtracted from X to give its new value as F/D (see equation (8)); 300 carries out the subtraction. Line 310 tests the size of the adjustment and, if it's not small enough to stop the procedure, sends the program back to 250 for another try.

(8) Line 330: calculates the APR (R) from the final value of X using equation (2).

(9) Lines 340 to 410: clear the screen, print out the results and stop the program. Line 390 multiplies R by 10, takes the integer portion and then divides by 10 to give a result truncated to one decimal place [Now rounded to one decimal place by the addition of '+.5'].

The Subroutines

(10) The subroutine at line 1000 prompts for data describing the advances. Line 1030 re-directs the program to the code dealing with multiple advances. Lines 1040 to 1070 deal with a single advance (referred to as the "Loan"). Line 1040 prompts for its amount; 1050 sets the time of the loan as zero; 1060 sets the total advanced to the loan amount. Lines 1090 to 1150 deal with multiple advances. For each advance; 1100 to 1120 prompt for the amount and time of the advance and 1130 adds the amount to the total advanced.

(11) Subroutine at line 2000: for each level; 2040 to 2060 prompt for the amount of the payments in the level and the length of the level (ie the number of payments it contains) and 2070 adds the amount multiplied by the length to the total repaid.

(12) Subroutine at line 3000: for each extra; 3040 to 3060 prompt for the amount and time of the extra and 3070 adds the amount to the total repaid.

(13) Subroutine at line 4000: for each advance; 4010 transfers the amount and time to variables A and T, 4020 calculates present value using formula (1) and subtracts it from the total for f(x) (see paragraphs 29 and 33), 4030 calculates the derivative using formula (9) and subtracts it from the total for f'(x).

(14) Subroutine at line 5000: line 5000 sets the beginning of the first level (B) to zero. For each level; 5020 transfers the amount of the level to A and calculates the end of the level (E) as B plus the length of the level, 5030 calculates the sum of the present values using equation (6) and adds it to the total for f(x), 5040 to 5060 calculate the sum of the derivatives using equation (12) (because of the size of the equation and the limit on program line length imposed by some pocket computer BASICs, it is broken into three lines, the variable Q being used to store partial results); 5060 adds the result to the total for f'(x). Line 5070 transfers E to B so it can represent the beginning of the next level (see paragraph 24(b)).

(15) Subroutine at line 6000: for each extra; 6010 transfers the amount and time to variables A and T, 6020 calculates the present value using formula (1) and adds it to the total for f(x), 6030 calculates the derivative using formula (9) and adds it to the total for f'(x).

Dealing with Series

66A. The following code can be added to extend the program to deal with simple series of repayments (ie series where all the repayments are the same amount):

35 DIM C(20,3) ... 125 INPUT "How many Series ";U ... 165 IF U>0 THEN GOSUB 7000 ... 275 IF U>0 THEN GOSUB 8000 ... 6060 : 7000 CLS 7010 PRINT "SERIES:" 7020 PRINT 7030 FOR N=1 TO U 7040 PRINT "Series ";N;" £"; 7050 INPUT " ";C(N,0) 7060 INPUT "start at ";C(N,1) 7070 INPUT "interval ";C(N,2) 7080 INPUT "number ";C(N,3) 7090 P=P+C(N,0)*C(N,3) 7100 NEXT 7110 RETURN 7120 : 8000 FOR N=1 TO U 8010 A=C(N,0):T=C(N,1) 8020 FOR Y=1 TO C(N,3) 8030 F=F+A*X^T 8040 D=D+T*A*X^(T-1) 8050 T=T+C(N,2) 8060 NEXT 8070 NEXT 8080 RETURN

66B. In the above code, line 35 DIMensions an array with sufficient space for 4 items of data on 20 series, line 125 asks the user how many series there are, line 165 triggers calling the subroutine at line 7000 to input the series data if there are any series and line 275 triggers calling the subroutine at line 8000 to calculate the present values and derivatives for the series. Looking at the two subroutines:-

(1) Subroutine at line 7000: for each series; 7040 to 7080 prompt for the amount of the repayments in the series and the start time, interval and number of repayments in the series. Line 7090 adds the amount multiplied by the number of repayments to the total repaid.

(2) Subroutine at line 8000: for each series; 8010 transfers the amount of the series to A and the time of the first repayment to T. For each repayment in the series 8030 and 8040 calculate the present value and derivative using formulae (1) and (9) and then add them to the totals for f(x) and f'(x). Line 8050 adjusts T to the time of the next repayment by adding the interval to the existing value.

66C. This code is only intended to provide a basic idea of how to deal with series. In fact, with this type of series, we could have used equation (7) and formula (14) to calculate the sums of the present values and derivatives for the entire series in one go. However, in a full implementation you would probably want to use the type of structure shown here and include facilities to deal with series where the repayments are of different amounts. You could do this by storing the amounts using a separate array and a pointer system, something like that described in paragraph 66(2) above, to access them, perhaps with a flag for each series indicating whether the amounts are the same - in which case you'd only need to store one amount in the array). You may also want to use a series facility to deal with cases like those mentioned in paragraph 26 where, although the repayments occur one or more calendar months apart, levels can't be used because the first repayment in the series is not a whole calendar month from the relevant date. This would require you to develop routines to calculate the period between two dates in days.

[Simple routines to do this are now available in a short Annex to this paper accessible by clicking here]

Example Calculations

67. The following are a number of brief examples of calculations performed using the program. As a start we'll consider the simple agreements already mentioned earlier in the paper:-

Example 1: First take a straightforward 'equal instalment' agreements such as those described in paragraph 35 and figure 4. In both cases a loan of £150 is repaid by equal monthly instalments of £15. In calculation (a) there are 11 repayments and in (b) there are 14:-

Example 1(a)

CALCULATION OF APR
==================

How many Advances ?1
How many Levels   ?1
How many Extras   ?0

Loan £ ?150

Level 1 £ ?15
Length ?11
Periods p.a. ?12

RESULTS:

TAP = £165
TCC = £15
APR = 21.3

Example 1(b)

CALCULATION OF APR
==================

How many Advances ?1
How many Levels   ?1
How many Extras   ?0

Loan £ ?150

Level 1 £ ?15
Length ?14

Periods p.a. ?12

RESULTS:

TAP = £210
TCC = £60
APR = 76.3

Example 2: illustrates a typical use of the levels system to deal with regular payments of varying amounts. A loan of £100 is repaid by 24 monthly instalments, the first 18 of £5 and the final 6 of £5.75 (taken from paragraph 18):-

CALCULATION OF APR
==================

How many Advances ?1
How many Levels   ?2
How many Extras   ?0

Loan £ ?100

Level 1 £ ?5
Length ?18
Level 2 £ ?5.75
Length ?6

Periods p.a. ?12

RESULTS:

TAP = £124.5
TCC = £24.5
APR = 23.6

Example 3: illustrates a typical use of the combination of levels and 'extra' payments. A loan of £12,500 is repaid by 59 monthly repayments of £275.60 and a final monthly payment of £189.60. In addition, the customer is also required to pay an administrative charge of £125 on the date of receiving the loan.

CALCULATION OF APR
====================

How many Advances ?1
How many Levels   ?1
How many Extras   ?2

Loan £ ?12500

Level 1 £ ?275.60
Length ?59

Extra 1 £ ?189.60
at time ?60
Extra 2 £ ?125
at time ?0

Periods p.a. ?12

RESULTS:

TAP = £16575
TCC = £4075
APR = 12.5

Example 4: a cooker with a cash price of £375 is advertised on 24 months credit with "nothing to pay for 3 months". The repayments are £27.50 per month. Remember, an ordinary equal instalment agreement (such as those dealt with in example 1) could justifiably be advertised as "Nothing to pay for 1 month", so there are actually only two instalment points at which no payments are made and not, as might appear from the wording of the advertisement, three. This type of agreement (or any case where there are gaps in the repayment pattern) can easily be dealt with by entering a level with repayments of zero:-

CALCULATION OF APR
====================

How many Advances ?1
How many Levels   ?2
How many Extras   ?0

Loan £ ?375

Level 1 £ ?0
Length ?2
Level 2 £ ?27.50
Length ?22

Periods p.a. ?12

RESULTS:

TAP = £605
TCC = £230
APR = 56.8

Example 5: A loan for £250 is taken out on 25 June 1986. There are a total of 6 quarterly repayments, 5 of £55.20 and a final one of £69.35, the first being made on 31 July 1986. The method of levels cannot be used here because the first period is not a whole number of calendar months. It is therefore necessary to calculate the time of the payments in days (from the relevant date) and enter all the payments as extras. As suggested earlier, you may wish to devise your own routines to perform these calculations for you and add them to the program. Here, we'll do the calculation 'by hand':-

Relevant date: 25 Jun 1986

Payment        Date        No. of days

   1        31 Jul 1986         36
   2        31 Oct 1986        128
   3        31 Jan 1987        220
   4        30 Apr 1987        309
   5        31 Jul 1987        401
   6        31 Oct 1987        493

CALCULATION OF APR
==================

How many Advances ?1
How many Levels   ?0
How many Extras   ?6

Loan £ ?250

Extra 1 £ ?55.20
at time ?36
Extra 2 £ ?55.20
at time ?128
Extra 3 £ ?55.20
at time ?220
Extra 4 £ ?55.20
at time ?309
Extra 5 £ ?55.20
at time ?401
Extra 6 £ ?69.35
at time ?493

Periods p.a. ?365

RESULTS:

TAP = £345.35
TCC = £95.35
APR = 57.9

Example 6: makes use of all of the facilities provided by the program to deal with a more complex case. A loan totalling £12,500 is advanced in two instalments of £6,000 and £6,500 six months apart. The borrower is charged interest at the lender's base rate of 10.75% per annum on the outstanding balance of capital and is required to make interest payments monthly. The loan lasts for 5 years and the borrower is required to repay the capital in one lump sum at the end of that period. In addition the lender charges the borrower £250 at the outset of the agreement to cover legal and administrative costs.

We know from the above that the interest payments for the first 6 months will be £6000 x (10.75/100)/12 = £53.75. For the remainder of the loan, the interest payments will be £12,500 x (10.75/100)/12 = £111.98

CALCULATION OF APR
====================

How many Advances ?2
How many Levels   ?2
How many Extras   ?2

Advance 1 £ ?6000
at time ?0
Advance 2 £ ?6500
at time ?6

Level 1 £ ?53.75
Length ?6
Level 2 £ ?111.98
Length ?54

Extra 1 £ ?12500
at time ?60
Extra 2 £ ?250
at time ?0

Periods p.a. ?12

RESULTS:

TAP = £19119.42
TCC = £6619.42
APR = 11.9

Conclusions and Disclaimer

68. This paper is lengthy and in places the maths used is rather complex. The intention behind providing such detail is that you should, if you want or need to, know both what to do to calculate an APR using the method described here and the background to why you're doing it. It is hoped that, in addition to the ready-made solution provided by the program listed above, the information in this paper will provide you with a set of tools to deal with any type of calculation you might meet.

69. Please remember that, although every effort has been made to ensure that the information contained in this paper is correct, because of the many different types of machines, languages and credit agreements in existence, it cannot be guaranteed that the results obtained using the method and program described here represent a complete and authoritative interpretation of the law.

Brian Stewart.
July 1987

(first revision, December 1992)
(second revision, May 1995)
(third revision, April 2000)