It's All in the Payment

The thought for the day centers around the seemingly ubiquitous client request of  "why is my payment different when I use your software"?  The specifics of the answer to that question permeates the core of what makes consumer credit math a more intimidating subject than at first glance.  Bottom line: there is no such thing as a single universal payment amount for a given set of loan data.

Obviously, judging from the construction of the opening question, the client has an expectation as to what the payment should be for a specific loan amount, term, and interest rate.  Very often that expectation is driven by the results from the ancient Monroe desktop that has been sitting on the file cabinet for the last 22 years.  "Everyone uses it" so the payment must be right even though, at this point in time, no one remembers what particular parameters were programmed into the box in 1989.

Contrary to what may seem like conventional wisdom, most lenders and point of sale dealers and representatives generally have a number of programs and applications that can take input data and generate a payment and other disclosure values.  So, without coordinating the nuts and bolts parameters of the math involved, the chance of two or more different pieces of software matching payment calculations on a regular basis is actually slimmer than you may think.

Payment calculations are driven by the process of prospective amortization.  The goal is to arrive at the payment that will amortize the loan, accruing interest at the stated interest rate over the stated maturity of the loan. 

Unlike the actual payment history, the amortization process used in creating a payment must assume all payments will be made as scheduled.  That is the only information available at the consummation of the contract.

The dominating wild cards in the process are the interest accrual method and time calendar in use.  In order to move through the theoretical amortization process, we have to have rules.  Those rules are often lumped together under the umbrella "interest accrual" but to really be accurate it takes more delineation than that.

Time calendars are the biggest reason systems produce differing payments for the same set of data.  The recognition of time periods is crucial in understanding if the quoted payment will amortize the credit transaction.

In determining how prospective interest will be assessed on the scheduled outstanding balances between payment dates it is a matter of recognizing the periods between two prospective dates, or events.  Is the time period from today, April 26th, until May 26th one month and the annual interest rate will be applied as 1/12 to the outstanding balance?  Or is it 30 days?  Will the rate be applied as 30/365 of the rate times the balance?  30/360?  or perhaps 30/366 if it is a leap year?    As you can see, it slices and dices in a number of distinct styles and models.  All potentially producing a distinct payment value depending on the loan data involved.

That is why, after 26 years of working to define precise specifications to produce accurate payments, I bite my tongue when I hear "Well, we use a 365 day year".  That indeed is a truthful description of the calendar on my wall but it doesn't provide enough information to decipher a lender's expected interest accrual process.

If we're focusing on "365", does that mean the 26th to following 26th is a month and any days outside that month earn interest at 1/365 of the annual interest rate?  or does that mean to assess 1/365 of the annual rate for 30 days if the time period is April to May? 31 days if May to June, etc.?  And, does "365" really mean we'll exclude leap year when it occurs?  Alone, "365"  creates many more questions than answers.

For a subject that, from the outside looking in, at first appears simple and plain, the complexities and details greatly outnumber the obvious.

I've learned not to jump on the bandwagon too swiftly and declare a payment "wrong" for a set of loan data.  Instead, "different" is a much more accurate and realistic approach when viewing a disclosed payment and attempting to evaluate if it is "right".  You have to understand the rules the payment computation operates under before making a judgment call.