top of page
  • Writer's pictureRick Haskell

Masterclass in Auto-Decisioning

Thought I’d take a break from collections to discuss loan originations, and in particular—your auto-decisioning system. I’ve seen many configurations, and have personally been involved with one that evolved over 20 years. There were many lessons learned, and I’ll try to summarize a few of them here. First, I’ll describe a typical lender’s natural evolution of this as I have seen it, and try to mention common mistakes. But first, my recommended architecture: The general approach is to focus on declining the worst apps first, and in 2 steps: Pre-bureau pull, then post-bureau pull. You save a few bucks by declining apps that don’t meet minimum job or residence time limits, along with minimum income requirements and a few other things prior to ordering a bureau. Understand that your decline module is where you are truly controlling cumulative net losses (CNLs), so the thinking is—if the app survives the Decline module, we want to approve it.

It’s important to think of your decision-architecture as a modular system. Each module has a specific purpose. While scores like FICO, Vantage, and your internal scores should play an important role in declining apps, it’s also important to create decline rules around single-attributes with specific ranges that have proven to be high-CNL segments in your portfolio. These single-attribute decline rules act as “stiffeners” that help prevent against wide swings in your vintage loss curves during times of economic stress. Note: you should be testing your vintage portfolios for high-CNL segments amongst all your variables for this specific purpose. Lendisoft has a Data Mining service that does just this, so contact us if you are interested.

Once the declines are dealt with, the focus changes to approvals, and pricing. While many lenders simply use score bands to set their APRs and Discounts, I recommend creating Programs (or Tiers) for this purpose. And once again, I recommend using single-attribute variables as “stiffeners” to ensure your top-tier borrowers not only have good scores, but also have a minimum number of performing tradelines (for example) in their credit bureau, and vice-versa with your lower-tier programs (for example forcing “thin credit profiles” into your lower tier programs).

Once the borrower is slotted into the right program, determining the APR and Discount is a simple lookup. Naturally, you’ll have your lowest pricing in your best program tiers, and setting these values should be a profitability exercise for each individual program. APR + DISCOUNT = GROSS YIELD; minus Annualized CNL, minus Cost of Funds, minus Cost of Operations = Net Profit Margin. Of all of these variables, the most volatile is your CNL%, so you should always be forecasting your CNLs for each program, and setting each program’s APR and Discount high enough to produce a nice spread of Net Profit Margin. Lendisoft can help you calibrate each program’s pricing to forecast profitability.

Some of you are probably wondering when I’m going to start talking about deal structure. Well, now is the time, and not before. It’s far too common to be comingling concepts around deal structure in one’s decline module. Bad idea. It’s best practice to decline apps based on what the borrower brings to the table—which is evidenced in their credit bureau and what’s stated on their credit application. Deal structure attributes like down payment, loan-to-value, payment amount, term, etc. are outside of this realm. So once you know which program the borrower has qualified for, then do a lookup to retrieve all the max deal structure limits for that program. For example, your top-tier programs should have more relaxed deal structure limits, while your lower-tier programs should have tighter limits to offset the additional risk.

Dealing with Co-Borrowers: it’s recommended that each borrower is assessed independently in the Decline module (or merged if your software has this capability); and if either borrower triggers on a rule, then you decline the deal. If both borrowers survive the decline module, then each should be tested in the program selection module and you should go with the best program that either borrower qualified for.

Biggest Pitfalls I’ve seen & My Best Practices:

  • Not keeping it simple is a problem; Not keeping it modular is a problem. I always say, you have to work really hard to keep things simple. Most decision platforms I’ve seen are littered with convoluted rules that are overfit to obscure situations that don’t even move the needle. Eventually these rules go forgotten despite remaining in the production system.

  • Document your auto-decision framework in just a few pages. Keep it high level, but include all the various rules so all stakeholders know they’re there.

  • Building scorecards for too many segments is a problem. Before you know it, things have shifted and what was highly predictive yesterday becomes weak today. Only do segmentation when there is an abundance of “lift” in the predicted results—and I mean ABUNDANCE. The best origination systems are a hybrid of score-based rules + criteria-based rules, mixed with some automated verifications + manual verifications.

  • Credit attributes is big business these days. Alternative data is highly marketed as well. Don’t be fooled into thinking this is going to replace your need for common-sense rules, manual effort in underwriting and verifications, or anything else. If you are already making significant use of traditional credit bureau attributes, the “old reliable” staples of the credit industry, alternative data is only going to slightly enhance the overall effectiveness of your decision model—let’s say 5% lift at best. Is it worth the extra cost and maintenance? Maybe, but those variables often have obscure definitions that are anything but transparent. When you can’t understand your own rules, and have deliberate knowledge and control of your decision model, you’ve taken a step backwards.

  • Avoid declining apps based on deal structure. Better to approve the applicant (assuming they survived your decline module) and to adjust the requested deal structure into something that fits. And if you want to approve “would-be” declines with exceedingly favorable deal structure requirements, only do this sparingly (e.g., “this one’s only approved with a max 75% LTV”). DO NOT make this approach a big part of your overall decision strategy as it undermines the basic philosophy of wanting to approve borrowers who have a pattern of paying their debts; not trying to “outsmart” nature, thinking you can turn a bad apple into a good one. You might get lucky now and then, but this is not scalable for the long term.

  • Develop a report that clearly details how many apps are getting declined (by decline rule), approved in each program, and everything else that is triggering throughout your decision program. Run this report frequently to notice when things are shifting around.

  • Develop a “before and after” report, patterned after the report mentioned just above, that details what will happen to your “mix” in all these categories “if” you commit your next desired change to production. You just may learn that making that change will have unforeseen consequences in other areas.

  • “Black Box” solutions are overrated. I’m all for automation, but there is a point of over-automating solutions to where you can’t see inside the box. Find that sweet-spot and develop your solutions around this “middle-ground” philosophy.

  • The deeper you lend into subprime, the more important it is to keep underwriting and verifications a manual process—it’s the best way to catch all the fraud.

  • Build a well-balanced platform that addresses common sense aspects of lending. Don’t be fooled by all the hype around AI solutions that replace all the hard work. Recognize where AI can help, and where it can’t.

If anyone would like help around setting up a robust decisioning system, Lendisoft does consulting in all areas of originations and collections. Check us out today!


Commenting has been turned off.
bottom of page