I was chatting with Tim Gill the other day about auto finance math, and the topic of recursion came up. Tim is one of the few vendors in this space with his own “calculations engine.” Otherwise, there are not many people who will talk to me about esoteric math problems. That’s why I write a blog.
People commonly describe Credit Life as a recursive calculation or, more properly, an iterative one. This is because the premium must cover the amount financed, and the premium is itself financed. So, if we write the premium as CLP, a function of the amount financed, A, then:
This is generally how people solve it. They run a few iterations, and CLP converges quickly. This is a preference, however, not a requirement. Assuming that the premium calculation is distributive over addition, which it is, we can just as easily set the problem up as:
… which can be solved analytically. This approach will work for most of your popular recursive calculations, like GAP insurance. For an example, let’s take a typical “cost per thousand” insurance calculation, where f works out to ten percent. You could go the infinite series route, which looks like this:
Or, you could simply work the algebra problem:
Now, I know what you’re thinking. You’re thinking that credit life calculations are far too complicated for this approach. You may also be thinking that the premium is based on the monthly payment, M, not A. In fact, these complaints are related. The payment is directly related to the amount financed, through the PV annuity factor, which combines the term and the APR into this handy relation:
So, when you see a payment formula like this one:
The insurance carrier is actually helping you, by combining the calculations for premium and monthly payment. By the way, the last time I checked, C# did not have the payment and related methods from VB and Excel. You are much better off coding your own PV annuity factor, and using it as described here.
Now, if you are designing a calculations engine, you may still prefer to use iteration, for the same reason that you may not want to algebraically reverse all your tax and fee calculations. It is better, though, to use your algebra and know your options, than to rely blindly on iteration.
Virag Consulting 