The Match Game

An interesting discussion I have often with members from both the industry and the regulators is the proper way to decide if a computed number is "right".

Generally, we see two schools of thought on this subject: one that seeks to "re-originate" the transaction in question and match the disclosed results, and the other which seeks to validate computed numbers by a predetermined set of rules.

I'll admit here at the outset of this discussion that I am an advocate of the second position and feel it is the proper way to determine if a credit calculation is accurate and thus "correct".

The real key to creating a loan transaction from scratch is the integration of interdependent computed values into the transaction at large. That may seem like a mouthful but the premise is something like this:

I want to know if the single premium credit life premium of $374.92 is correct, but the premium coverage is gross payoff so the premium is based on the total of payments. I can't figure the total of payments until I compute the payment. The payment can't be computed until I arrive at the principal amount but the principal amount includes the life premium so...........

You see how it goes. The circular nature of numerous iterations is at the center of the requirement that all computed values be integrated accurately into a credit transaction for it to be valid.

An attempt to start at the beginning with, say, a $5,000 proceeds value and re-create the transaction exactly and also match the premium can be a truly daunting, and perhaps superfluous, task.

First, the interest accrual calendar has to be the same as the transaction in question, along with the payment rounding of course. Speaking of rounding, all intermediate rounding of the life rate itself, premiums values, and accrued interest amounts must also match to the penny.

So if it's a 60 month transaction, I've got at least 3 things that have to match exactly 60 times in a row.

Remember that the value you want to prove is correct, comes from software utilizing specific code written by a specific programmer or developer. How many programmers do you know that write code identically even within the same office let alone 1,000 miles apart and working independently?

And, if I don't match, which of those three potential variables is out of sync? or maybe two of the three? There are way too many variables and unknowns to try and coordinate in order to get an accurate picture. Sometimes the results may match but you can't be absolutely certain it's for the right reasons.

A much better approach is to know the properties, parameters and pertinent variables included in the transaction and use the true disclosed loan values themselves to prove right or wrong.

For instance, in the above example if the gross credit life rate was $0.40 per $100 per year and the computed and disclosed monthly payment was $310.89 for 60 months, then the proper premium is $373.07.

Now, whether the disclosed contract value of $374.92 is acceptable in light of this evaluation is another level of scrutiny, and a different topic altogether, that I won't try address at the moment. For today, I'm sticking to the "how to" process.

However, in this validation scenario it is clear what the proper premium is for the rate filed and the disclosed monthly payment of $310.89. This validation has used the actual contract payment, amount financed, and filed insurance rate to arrive at the result.

It doesn't matter whether the mission is validation of insurance premiums, maximum allowed interest charges, or contractual rates of charge, a key ingredient is the employment of the disclosed contractual payment amount(s).

The payment disclosed and agreed to in the contract is a major determinant of interest earnings and principal reduction for any given period during the transaction.

The imposition of a theoretical payment through the process of "re-solving" can skew the profile of the loan liquidation so that it no longer resembles the actual transaction. In that case, re-solving will produce a result but not necessarily one that provides an accurate actuarial analysis of the calculation under scrutiny.

At Carleton we use the process of amortization to provide a precise and accurate validation of the data on a consumer credit contract. The article in our Spring 2011 "of Interest" newsletter, "The Power of the Schedule", lays out the basics of this approach in more detail.

The article can be found at http://www.carletoninc.com/services/ofInterest.asp.

We constantly evaluate whether we are keeping our "eyes on the prize" when it comes to ensuring our clients are in compliance when using our calculations. The key is not to be distracted by available peripheral data and approaches that don't really focus on the issue at hand.