An interesting discussion I often have 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 that 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 out 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, premium 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 to 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 to 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. 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 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.

2) Determine if the fee is included in any regulated “charge” amount for the 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 purposes 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 the state maximum charge evaluation.

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.

There are days when I absolutely hate the month of February.  And not just during that month with its sub-zero temps, dark days and endless snow, but when the fact that it has only 28 days wreaks havoc on system lending calculations.

We work to reconcile payment calculations from literally scores of other systems during our project definition process with clients and users. The key is to determine how a particular routine deals with February.  That is as challenging a diagnostic exercise as it gets.

Too many design characteristics draw from the outmoded “360-day year” methodology of 30 years ago.  February 1st to March 3rd may indeed be “30 days,” but it most certainly is not a calendar month and Regulation Z, for instance, certainly isn’t going to recognize that time period as 1/12 of a year.

It’s not merely February but the fact that months have different lengths in days.  A forgotten fine point is that while Appendix J to Reg Z says that “All months shall be considered equal”, actual calendar days have to be counted for fractional month periods.  That doesn’t jibe with many “360-day year” conceptions that we see put in use.

Like everything else, the devil is in the details.  Consider January 31st to February 28th; it’s a month when counting forward for interest accrual purposes, but can be a fraction of a month with the Federal Calendar in computing the APR.  That first glance at the dates can be deceptive.

When gathering information to define software, one of the critical areas for accurate disclosure is determining the nature of any fees that will be charged by the lender. A really popular industry description of specific fees is that “this fee affects the APR”.

It’s become clear that statement is intended to mean that a fee will “make the APR a different value than the interest rate” (Reference: The Interest Rate and the APR).  From our consumer credit math purist standpoint, every fee “affects” the APR.

All fees in a lending transaction are either in the Amount Financed (Truth in Lending Act definition) or the Finance Charge (also TILA defined).  The sum of the AF + FC equals the Total of Payments.  As a general rule, the AF and FC are mutually exclusive and collectively exhaustive.  Fees are either in one or the other, but they can’t be in both.

Consequently, a fee that is included in the TILA Amount Financed does indeed affect the APR calculation since the APR measures the relationship of the Amount Financed to the Finance Charge over the time period of the loan.

So, our goal in defining software projects is to help clients determine which fees can potentially be required to be in the TILA finance charge.

In the last few months, we have had a number of inquiries from clients about how to pass our calculation engine the right information for single advance, single payment transactions.

There seems to be a degree of uncertainty when dealing with these types of loans.

Maybe it’s because these types of transactions represent the simplest calculations that we do and the expectation is that the concept should be more difficult.  In reality, it is a linear I = P x R x T type environment and there aren’t the thousands of behind-the-scenes iterations that are necessary to compute a precisely integrated declining balance closed-end credit transaction.

It seems the first inclination is for a system to collect and pass us the information as though it were a monthly transaction with a series of $0.00 payments followed by one “balloon payment” at maturity.  For instance, a twelve-month single-pay loan would have 11 $0.00 payments and then one large payment of principal and interest.

That situation may seem analogous to a single payment transaction, but it poses two prominent issues with regard to the disclosure computations.

The first is that when assumed to be ‘monthly’ in nature, interest accrues on a theoretical monthly basis and presents potential rounding options.  Traditional near rounding, as in periodic transactions, can create an interest charge that is materially larger than a linear calculation where the only rounding is done once at completion.

The more significant issue is the Truth in Lending APR calculation.  The rules in Appendix J of Regulation Z recognize ‘events’ in order to establish a unit period for APR computation.  Payments of $0.00 are viewed as events, regardless of dollar amount, in order to take into account the time value of money.  That practice establishes the unit period for APR computation as monthly rather than the term of the transaction as prescribed in Appendix J.

The result is that the APR computed for a monthly unit period with 11 $0.00 payments and a final of $10,799.80 for a $10,000 loan is 7.719%.  Computed properly as a single advance, single payment loan, the accurate APR disclosure is 7.998%.  The difference of .279% is well outside the 1/8 of 1 percent tolerance Regulation Z allows.

There are instances where our communication is initially hindered by the use of labels.  Since we are creating routines to ensure compliance with regulatory requirements, the labels we use have strict definitions per the appropriate regulation.  A specific lender, however, may develop names for lending programs internally within their institution that have a more esoteric meaning.

We view “single payment” as a transaction where the borrower makes only one payment during the life of the loan.  We have seen the term “single payment” used to also characterize a loan program where interest-only payments are required and a single principal and interest payment is due at maturity.  Those two instances, both named “single payment,” require separate and distinct procedures for computing the Truth in Lending annual percentage rate.

It is vitally important to keep units of measure and other pertinent characteristics consistent when performing any consumer credit calculation.  Rather than “apples and apples,” the result may be a fruit salad not pleasant to the compliance taste buds of the lender.

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 permeate 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, 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 the 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 the 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.

One question we field on a weekly, some weeks daily, basis revolves around the Truth-in-Lending APR disclosure in the “fedbox” being a different value than the originating interest rate. A different value, meaning the interest rate was 10.00,% but the disclosed TILA APR is 9.98%.

The view in the consumer finance industry that “the APR and the interest rate should be the same if I don’t have any fees” is not only predominant but has reached an urban legend type of status. Too many times, the answer to my inquiry as to why the above statement is true has been “because it is”. Sound logic.

In reality, the two rates are truly distinct values. They have separate purposes and functions. One is to compute the interest charge for the transaction according to the lender’s choice of accrual, which is in step with their particular philosophies and policies; the other is to measure the cost of credit in a standardized fashion in an attempt to provide consumers with a yardstick in comparing competing deals.

The interest rate is the dominant factor in determining a loan’s magic number, the monthly payment. The prospective interest plus the loan principal determines the scheduled total of payments.

Once the payments and all the other disclosure numbers have been computed, then the Truth-in-Lending APR can be accurately computed and disclosed. It is entirely a back-end number. It is often erroneously thought that the APR creates or drives other loan values, but it does not. It merely measures the result of the other computations and provides a common barometer for the consumer to evaluate and compare credit deals.

The changing nature and operations of the lending industry have brought the differing characteristics of these rate values out into the light. For many years, the TILA APR produced a rate that was always the same value as the interest rate and it still will on occasion. But in particular, the advent of “simple interest” transactions with daily interest accrual has changed the landscape dramatically.

Back in the day, when interest was nearly always computed on a monthly basis, aka “360-day year”, the APR and the interest rate, in the absence of pre-paid finance charges, would end up with the same value.

That is because Regulation Z mandates that the APR be computed on a “unit-period” basis. (We’ll disregard the U.S. Rule implications here; that is another entire blog that could stretch for several city blocks) So when repayment terms on loans were predominantly monthly in the industry, both the interest charge and the APR were computed monthly. A 10% interest rate would work out to be a 10% APR. Most of us who have been around this industry for 20 years or so remember that “it was always that way”.

Think about today’s lending practices and the prevalence of “simple interest” transactions. One of the hallmarks of simple interest is computing the interest charges on a daily basis. Each calendar day between scheduled payment dates accrues interest at 1/365 of the annual rate. So, that daily interest produces a dollar interest charge that, in the absence of fees, becomes the TILA finance charge by definition.

When the APR recognizes that the loan’s total dollar charge, it assumes time periods are monthly and computes an APR accordingly. Interest computed daily and an APR computed monthly are not “apples and apples”.

However, remember that one of the roles of the TILA APR is to standardize the cost of credit rate and provide a “level playing field” gauge of the credit cost regardless of differing parameters, such as interest accrual, employed by differing lenders.

If the dollar interest charge for 36 months on a daily basis is greater than the dollar charge for 36 months on a monthly basis, it only makes sense that the APR would be higher.

It is not unusual for a 14% interest rate computed on a daily basis for a monthly loan to yield an APR of 14.02%. Both rates are accurate, they simply operate with different rules.

One important caveat for lenders with a policy of operating at state maximum interest rates is recognizing when the practice of daily interest accrual may produce an APR that exceeds the computational rate. Many states have statutory language that equates the maximum rate with the TILA APR. Some states regulate interest and some regulate the equivalent of the TILA finance charge. Like so many things in today’s world, what used to be simple isn’t necessarily so any longer.