F&I Products – Virag Consulting

Biweekly Payment Magic

A while back, I did some foundational work for a leading biweekly payment service. That is, the math part, which I will reprise here. Biweekly works best in a climate of high interest rates and, unfortunately, soon after this project, the Federal Reserve dropped their reference rate to zero. The Fed has not been persistently above 2% until recently, and biweekly is once again looking good.

The featured chart shows a scenario first constructed by my erstwhile partner Phil Battista. I call it the “magic trick” because the customer in this scenario has financed an extra $3,250 with no change to the term, APR, or payment. Before presenting the trick, here are some basics about biweekly.

Biweekly Payment Plan Basics

In Canada, the banks offer loans with native biweekly payment schedules, and dealers feature them in their advertising. Here in the States, you have to use a service. The service collects payments biweekly via direct debit and manages the lender to accelerate the amortization.

Here is an example. According to recent Cox data, the average price of a new car is now above $49,500 with an APR of 7.0% and a 72-month term. By the way, this survey does not include luxury brands, and some people are financing up to 84 months.

Below, I have modeled this “average” loan showing monthly versus biweekly payment schedules. This is showing the amortization only, omitting whatever fees the biweekly service may charge. You can see that the loan is paid off seven months early.

If you’re using longer terms to fit customers into payments, biweekly will shorten the trade cycle a bit. Also, credit-challenged buyers may be better off with direct debit synched to their paychecks.

Nostalgia Alert: coding for the U.S. Equity project was originally done in C# by my son, Paul, who would have been around fourteen at the time. We were making an OO model to include all loan and lease instruments as subclasses. Coding for this article was done by me, in Python, which is 10X easier.

The Magic Trick

If you compare the two charts above, you can see graphically how Phil’s trick works. Instead of starting your biweekly loan at the same amount and having it end earlier, you start it higher and aim to end on the same date.

The trick works because half the monthly payment is higher than a native biweekly payment would be – by $33 in this example. The customer makes the equivalent of thirteen monthly payments per year, and the bank loses a little bit of interest income. Here are the steps:

Increase the amount financed, which will increase the monthly payment.
Increase the term until the monthly payment comes back down to where it was.
Use the biweekly program to bring the term back down to where it was.

Congratulations, you can now finance more product with the same monthly payment. I covered the concept for menu systems in Six Month Term Bump. To do goal seeking, as I’ve shown here, you will need some Python (or a precocious teenager).

Schrödinger’s Combo Product

NADA has recently published a model policy for properly selling F&I products, i.e., without running afoul of the Attorney General. It includes the disclosure formerly known as the AutoNation Pledge, and a new procedure which seems to be taking the place of the old-school waiver form. I say “seems” because there is no mention of the old form, which I believe has something to do with nuclear physicist Erwin Schrödinger.

Prior to the sale of a VPP, the Dealership will request the customer’s acknowledgement of the election to purchase or decline each selected VPP or VPP bundle.

As everyone knows, subatomic particles exist in an indeterminate state until they are pinned down by measurement. For example, if you have a radioactive isotope of Cesium, you can’t tell whether it has decayed until you aim your Geiger counter at it. Not only can you not tell what state the atom is in, it is not definitely in any state until you measure it.

To show how this contrasts with traditional physics, Schrödinger proposed the following thought experiment. Imagine there is a cat in a box with the Cesium rigged to kill the cat when it decays. According to the Uncertainty Principle, the cat is both alive and dead at the same time.

Similarly, the F&I waiver requires each product to be either accepted or declined. You bought the dent protection, so it prints in the green column, but you turned down roadside assistance. It prints in the red column. To save a few dollars, you are willing to leave your family stranded. Please sign here to confirm.

But what if dent and roadside – and key and windshield – are part of the same bundle? You only bought one of the components, so it would be misleading to print it in the green column. On the other hand, you are not going to confirm declining the bundle, because you did buy part of it. So, in which column does this product belong?

Here are some ideas:

The menu system should account for the child products and print them individually on the waiver. It should also count them separately as product sales.
The menu system should print the coverage description, and the coverage description should state which components were accepted.
Providers should offer bundles all or nothing, and not allow them to be split up.

Unlike Schrödinger, you will not win the Nobel Prize for solving this one – but you can provide some guidance to your fellow F&I practitioners. Click the link below to register your answer.

Workflow for Online Car Buying

A few years ago, I published a precedence diagram for the key operations of online car buying. I was arguing against a linear process, and calling attention to some deadlocks. Since then, I have been following the industry’s experiments with new process models, and coming to realize that these deadlocks are the great, unanalyzed, obstacle to process reform.

Practices that seem unfair, deceptive, or abusive may actually be crude attempts to solve the deadlock problem.

One example of a deadlock is that you can’t quote an accurate payment until you know the buy rate, and for that you need to submit a credit application. This is usually solved by iteration. You do a pre-approval or quote the floor rate, and then change it later.

Likewise, you can’t price protection products until you know the vehicle, but the customer wants to shop by payment. Protection products are also priced by term, and you don’t know the desired term until you finish structuring the deal.

In fact, even the customer’s choice of vehicle depends on the monthly payment, which is downstream of everything else. Virtually the only operation that’s not blocked by another operation is valuing the trade.

Like an interlocking puzzle, “we don’t know anything until we know everything.” Choosing any one item to lock first, without iteration, will result in a suboptimal deal – buying too much car, for too long a term, or overlooking the protection products.

Practices that seem unfair, deceptive, or abusive may actually be crude attempts to solve the deadlock problem. For instance, quoting a payment with some leg in it, or goal-seeking the full approval amount.

Can you see how this ties into current debates about the hybrid sales model? F&I presents a menu with a six-month term bump, which might not be optimal, just to compensate for too tight a payment from the desk.

Fortunately, in the world of online car buying, the customer is free to resolve deadlocks through iteration. This means:

Set up the deal one way
Change any feature, like the term
The change “cascades,” undoing other features
Revisit those other features
Repeat until all features look good together

The in-store process does not support iteration well, and probably never will, but an online process can. All you need is the well-known concept of a “dirty” flag, to keep track of the cascading changes, along with navigation and a completeness gauge to guide the customer through steps #4 and 5.

You could analyze step #3 at the level of a dozen individual features. I made that chart, too, but I believe it’s more useful to collect them into the canonical five pages shown here.

By the way, I have previously described the products page in some detail, along with the analytics to drive it. Discussion of the “random survey question” is here. Today’s diagram contemplates a mobile app, as do my recent posts, but the same approach will work for a web site.

All about Surcharges

Now here is an article for specialists only. Menu system developers must know how to correctly acquire and present service contract rates, and surcharges are the most difficult feature. Integrators and product providers also struggle with this, and I am writing today in hopes of establishing some industry norms.

We start with surcharge policy, from the provider’s perspective, and then data transfer and presentation issues for the menu system.

A surcharge represents an ad hoc increase to the claims risk, and therefore the price, of a service contract. It lies outside the conventional pricing model, which is:

Risk Class – it costs more to service a Camry than a Corolla
Coverage – which parts and services are covered
Term – contract duration in months and miles
Deductible – claims risk is mitigated by a higher deductible

A surcharge is an extra feature tacked on to the pricing model. For instance, the provider might want an extra $200 to cover a vehicle having a modified suspension, a turbocharger, or four-wheel drive, or if the customer intends to use the vehicle commercially.

Adding a flat dollar amount to the price is straightforward, but not especially accurate from a claims perspective. That turbocharger will grow more risky as time goes on, so it is smart to have the surcharge amount increase with the term.

Note that you do not need to stipulate a four-wheel drive surcharge for Subaru. They are all four-wheel drive, and so you can account for this risk in the vehicle classification. Fixed (irremovable) features of the vehicle may be treated either as surcharges or risk classes. In this example, four-wheel drive is handled as a class code bump.

Likewise, deductibles can be treated as surcharges. This is an efficient way to represent them in a printed rate guide, where a choice of deductibles would mean many additional pages. In the example below, the rate guide is printed with a base deductible of $50 and four more as surcharges. Note that the surcharge amounts vary with the term mileage.

Warranty Solutions uses a similar approach, except that the surcharge amounts vary with the cost of the base contract. They reckon that the risk associated with the vehicle, coverage, and term is already reflected in the cost, and so the surcharge should be higher on a higher-cost contract. In my time as a consultant, I have seen everybody’s rate guide, and every possible way to handle surcharges.

It is important to recognize that a printed rate guide is just one way to represent the provider’s evaluation of risk. As with Sapir’s theory of language, the provider’s actuary can only evaluate risks that can be expressed by the pricing model.

Where rates are returned via web service, there is no need to treat deductibles as surcharges. They should be an explicit part of the pricing model, as above. Where the VIN is supplied as input, likewise, there is no need to specify vehicle surcharges.

Many rate guides distinguish between “mandatory” and “optional” surcharges, but all surcharges are required to be levied where applicable. Therefore, the usage I prefer is:

Mandatory Surcharge – We know it from the VIN, like a turbocharger
Optional Surcharge – We have to ask, as with commercial use

The user experience for a mandatory surcharge is simply to notify that we have already applied it to all rates in the web service response. For optional surcharges, the menu system must provide a checkbox or some other way to apply it.

In either case, it is best for the web service to apply the surcharge to all rates in the response. This allows for a smaller payload, and no chance for error. The only reason to send rates both with and without an optional surcharge is if the menu system lacks the ability to request it up front.

Menu systems today already have user controls for the well-known surcharges, like commercial use, lift kit, snowplow, van conversion, warranty preload, synthetic oil, and rental coverage. As a developer, I don’t like the idea of hardcoding these controls. I would rather the menu system generate the controls at deal time, using a separate web service to obtain the list.

There is one kind of surcharge that must be included separately in the rate response. These are additions to coverage which the F&I Manager may upsell at deal time. The mockup below shows the addition of optional electrical to one grade of coverage, which is included with the higher grade.

Because the F&I Manager may toggle this surcharge dynamically, there is no alternative but to include it in the rate response. This means an extra branch at the coverage node, assuming a tree structure, or else sprinkle the surcharge among the leaf nodes and make the menu system do the math.

Upsell Surcharge – We may choose it dynamically at deal time

Either way, dynamic surcharges will bloat the rate response. The workaround we used at MenuVantage was to treat them as optional surcharges, above, and ask the F&I Manager to choose prior to rating. I frankly hate dynamic surcharges, a prejudice from my menu days, but people evidently find them useful.

That about does it for surcharges. If anyone has anything to add, in the spirit of setting industry norms, please write in.