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.

A Fee by Any Other Name....

A particularly key compliance component of our project definition process for new clients is the analysis of the properties associated with any fees paid by a consumer as part of a prospective credit transaction.

 Unlike mortgage lending where some fees have common labels and are universally understood, e.g. appraisal fees, title examination fees, property survey fees etc., fees associated with personal loans, small loans, and retail sales aren't always transparent based solely on the fee name.

Our focus is two-fold; 1) determine if the fee is part of the finance charge for Truth in Lending disclosure purposes, and 2) determine if the fee is included in any regulated "charge" amount for specific state maximum charge evaluation.

The heart and soul of the Federal Truth in Lending Act is really the dollar finance charge, aka "cost of credit". When Truth in Lending first came into being the basic rule of thumb was that "every fee is part of the finance charge, with a few exceptions".  That has evolved over the last 42 years to a process of "some fees are, some fees aren't" based on certain criteria.

State maximum rate statutes generally declare that any statutorily authorized fees either "are" or "are not" included in the maximum amount the particular statute regulates. 

What is often confusing is that while an authorized "processing fee" in a specific state may not be included in the state's maximum charge amount, that same fee is most certainly included in the TILA cost of credit.  To exacerbate the mental congestion that often accompanies trying to clearly digest and segregate two separate sets of rules is that the label used for both state and federal purpose may be identical; "finance charge".

So, for our purposes of making sure both state and federal calculations are accurate and compliant, we do need to know the name/label of a particular fee but we're much more interested in whether it is a TILA finance charge and part of the state maximum charge calculation.  Stating "we charge a service fee" is merely a starting point in the decision making process of how to accurately portray that fee in a "live" credit transaction.

The key is to remember that fees must be evaluated on two separate levels; 1) whether they are included/excluded for state maximum charge evaluation, and 2) whether they are included/excluded for the purpose of determining the Truth in Lending Act finance charge dollar cost of credit. These represent two separate processes to attain two separate compliance goals.