All posts by Peter Accorti
At some point a lender may need to issue an RFI or an RFP for a credit decisioning system. In this latest installment of “working with vendors” let’s dive into some best practices for writing RFIs and RFPs that will help you more quickly and efficiently understand the capabilities of a vendor. First, have one person (or at most a very small group) review the document before it goes out to vendors. Too often these kinds of documents seem like they’re just cut and pasted together without any concern if they paint a coherent picture. If it’s worth the time to write an RFI/RFP, then it’s worth the time to get it right so that the vendor responses make sense. If your document paints an inconsistent picture, a vendor may not know what products will best serve your requirements. In turn, precious time will be wasted in discussions around what’s being proposed. Here are some things to make clear in the document: For what part of the credit life cycle does this RFI/RFP apply (prospecting, origination, account management or collections)? If the request covers more than one part of the life cycle, make clear which questions apply to which part of the life cycle. Do you need a system that processes in batch or real-time requests (or both)? For example, a credit card account management solution can process accounts in batch (for proactive line management), in real time (for reactive requests) or possibly even both. Let the vendor know what it is you’re trying to do, as there may be different systems involved in processing these requests. Do you want this system hosted at the vendor, a third party (like AWS, Azure, etc.) or installed on premises? If you have a preference, let the vendor know. If you have no preference, ask the vendor what they can support. In general, consider playing down or skip detailed pricing questions. There’s nothing wrong with asking for a price range. For credit decisioning systems, detailed pricing is difficult for the vendor since there are often high levels of unknown customization to do. A better question might be, “What things will the vendor have to know in order to accurately price the solution? What are the logical next steps to get more accurate pricing? What’s the typical range of pricing in a solution such as this and what drives that range?” Will you be acting as an aggregator? Sometimes systems are created as front ends to several lenders. For example, a client may want to create a website where a borrower can “shop” among several lenders. This is certainly doable but carries with it a whole host of legal, compliance, business and technical questions. In my opinion, I’d skip the RFI/RFP in this situation and have a robust sit down directly with the vendors. This option will likely be far more productive. Ask more open-ended questions. “How does the solution perform task X?” as opposed to, “Do you support Y?” Often, there’s more than one way to accomplish a task. Asking more open-ended questions will yield a more comprehensive answer from the vendor rather than a simple yes or no response. It also gives you the opportunity to learn about the latest decisioning techniques. Be careful that you have not copied old RFP questions that are no longer relevant. I’ve had clients ask if we support Bernoulli Boxes (a mid-80s kind of floppy disk), or whether we support OS/2, etc. I’ve even had questions about supporting a particular printer. These kinds of questions are centered on the support of the operating system and not a particular vendor’s credit decisioning software. Instead of asking yes/no technology questions, ask for a typical sample architecture. Ask what kinds of APIs are supported (REST, SOAP/XML, etc.). Ask about the solution’s capabilities to call third-party systems (both internal and external). Ask fewer, but more in-depth questions. If the solution needs screens, be clear which screens you’re talking about. Do you need screens to make rule adjustments or configuration changes? Do you need screens for manual review or some sort of case management? Do you need consumer-facing screens where borrowers can type in their application data? If you need screens, be clear on the task the screens should perform. If you have particular concerns, ask them in an open-ended way. For example, “The solution will have to exchange file-based data with a mainframe. How can your solution best satisfy this requirement?” In general, state your requirement not the technology to use. A preamble or brief executive summary is useful to get the big picture across before the vendor delves into any questions. A paragraph or two can go a long way to help the vendor better assess your requirements and provide more meaningful answers to you. This works well because it’s easier to give the big picture in a few paragraphs as opposed to sprinkled around in multiple questions. To summarize, be clear on your requirements and provide a more open-ended format for the vendor to respond. This will save both you and the vendor a lot of time. In section three, I’ll cover evaluating vendors.
Perhaps your loan origination system (LOS) doesn’t have the flexibility that you require. Perhaps the rules editor can’t segment variables in the manner that you need. Perhaps your account management system can’t leverage the right data to make decisions. Or perhaps your existing system is getting sunset. These are just some of the many reasons a company may want to investigate the marketplace for new credit decisioning software. But RFIs and RFPs aren’t the only way to find new decisioning software. After working in credit services decisioning for over 20 years — and seeing hundreds of RFPs and presenting thousands of solutions and proposed architectures — I’ve formed a few opinions about how I would go about things if I were in the customer’s seat and have broken that into a three-part series. Part 1 will cover everything up to issuing an RFI or RFP. Part 2 will discuss writing an RFP or RFI. Part 3 will cover evaluating vendors. Let’s go. If you’re looking to buy new decisioning software, your first inclination might be to issue an RFI or an RFP. However, that may not be the best idea. Here’s an issue that I frequently see. Vendors are constantly evolving their products. How a product did feature X two years ago might be completely different now. The terminology that the industry uses might have changed, and new capabilities (like machine learning) might have come about and changed whole sets of functionalities. The first decision point is to ask yourself a question, “Do I know exactly what I want or am I trying to generally learn what is out there?” An RFI or RFP isn’t always the greatest way to exchange information about a product. From a vendor’s standpoint, a feature-rich, complex system has to be reduced down to a few text answers or (worst yet) a series of yes or no answers. It all boils down to nuance. On many occasions, I’ve faced a dilemma when answering an RFP question, “This question is unclear; if the customer means X, the answer is yes; if they mean Y, the answer is no.” If I were in a room with the customer, I could ask them the question, they could provide clarification and I could then provide the accurate answer. There would be more opportunity to have a back and forth, “Oh when you said X, this is what you meant ….” All of that back and forth is lost with an RFI or RFP, or at least delayed until the (hopefully selected) vendor gets a chance to present in front of a live audience. Also, consider that vendors are eager to educate you about their product. They know exactly how the product works and they’re happy to answer your questions. It’s perfectly reasonable to go to a vendor with prewritten questions and thoughts and to pose those questions during a call or demonstration with the vendor. Nothing would prevent a customer from using the same questions for each vendor and evaluating them based on their answers. All of this can be done without issuing an RFI or RFP. In conclusion, I’d offer the following points to think about before issuing an RFI or RFP: A customer can provide questions that they want answered during a demonstration of a credit decisioning product. These same questions can be used to provide an initial assessment of several vendors. A customer’s understanding of a vendor’s capabilities is likely 10x faster and deeper with an interactive session versus reading the answers in a questionnaire. Nuanced and follow-up questions can be asked to gather a complete understanding. Alternative solutions can be explored. This exercise doesn’t have to replace an RFP but instead can better inform the customer about the questions they need answered in order to issue an RFP. Don’t be afraid to talk to a vendor, even if you’re not sure what you want in a new product. In fact, talk to several vendors. More than likely, you’ll learn a lot more via a discussion than you will via an RFI questionnaire. What’s good about an RFI or RFP is coming in with prepared questions. That way, you can judge each vendor using the same criteria but, if possible, get the answers to those questions via an interactive session with the vendors. Next: How to write an effective RFP or RFI.
Intuitively we all know that people with higher credit risk scores tend to get more favorable loan terms. Since a higher credit risk score corresponds to lower chance of delinquency, a lender can grant: a higher credit line, a more favorable APR or a mix of those and other loan terms. Some people might wonder if there is a way to quantify the relationship between a credit risk score and the loan terms in a more mathematically rigorous way. For example, what is an appropriate credit limit for a given score band? Early in my career I worked a lot with mathematical optimization. This optimization used a software product called Marketswitch (later purchased by Experian). One caveat of optimization is in order to choose an optimal decision you must first simulate all possible decisions. Basically, one decision cannot be deemed better than another if the consequences of those decisions are unknown. So how does this relate to credit risk scores? Credit scores are designed to give lenders an overall view of a borrower’s credit worthiness. For example, a generic risk score might be calibrated to perform across: personal loans, credit cards, auto loans, real estate, etc. Per lending category, the developer of the credit risk score will provide an “odds chart;” that is, how many good outcomes can you expect per bad outcome. Here is an odds chart for VantageScore® 3 (overall - demi-decile). Score Range How Many Goods for 1 Bad 823-850 932.3 815-823 609.0 808-815 487.6 799-808 386.1 789-799 272.5 777-789 228.1 763-777 156.1 750-763 115.6 737-750 85.5 723-737 60.3 709-723 45.1 693-709 33.0 678-693 24.3 662-678 18.3 648-662 14.1 631-648 10.8 608-631 7.9 581-608 5.5 542-581 3.5 300-542 1.5 Per the above chart, there will be 932.3 good accounts for every one “bad” (delinquent) account in the score range of 823-850. Now, it’s a simple calculation to turn that into a bad rate (i.e. what percentage of accounts in this band will go bad). So, if there are 932.3 good accounts for every one bad account, we have (1 expected bad)/(1 expected bad + 932.3 expected good accounts) = 1/(1+932.3) = 0.1071%. So, in the credit risk band of 823-850 an account has a 0.1071% chance of going bad. It’s very simple to apply the same formula to the other risk bands as seen in the table below. Score Range How Many Goods for 1 Bad Bad Rate 823-850 932.3 0.1071% 815-823 609.0 0.1639% 808-815 487.6 0.2047% 799-808 386.1 0.2583% 789-799 272.5 0.3656% 777-789 228.1 0.4365% 763-777 156.1 0.6365% 750-763 115.6 0.8576% 737-750 85.5 1.1561% 723-737 60.3 1.6313% 709-723 45.1 2.1692% 693-709 33.0 2.9412% 678-693 24.3 3.9526% 662-678 18.3 5.1813% 648-662 14.1 6.6225% 631-648 10.8 8.4746% 608-631 7.9 11.2360% 581-608 5.5 15.3846% 542-581 3.5 22.2222% 300-542 1.5 40.0000% Now that we have a bad percentage per risk score band, we can define dollars at risk per risk score band as: bad rate * loan amount = dollars at risk. For example, if the loan amount in the 823-850 band is set as $10,000 you would have 0.1071% * $10,000 = $10.71 at risk from a probability standpoint. So, to have constant dollars at risk, set credit limits per band so that in all cases there is $10.71 at risk per band as indicated below. Score Range How Many Goods for 1 Bad Bad Rate Loan Amount $ at Risk 823-850 932.3 0.1071% $ 10,000.00 $ 10.71 815-823 609.0 0.1639% $ 6,535.95 $ 10.71 808-815 487.6 0.2047% $ 5,235.19 $ 10.71 799-808 386.1 0.2583% $ 4,147.65 $ 10.71 789-799 272.5 0.3656% $ 2,930.46 $ 10.71 777-789 228.1 0.4365% $ 2,454.73 $ 10.71 763-777 156.1 0.6365% $ 1,683.27 $ 10.71 750-763 115.6 0.8576% $ 1,249.33 $ 10.71 737-750 85.5 1.1561% $ 926.82 $ 10.71 723-737 60.3 1.6313% $ 656.81 $ 10.71 709-723 45.1 2.1692% $ 493.95 $ 10.71 693-709 33.0 2.9412% $ 364.30 $ 10.71 678-693 24.3 3.9526% $ 271.08 $ 10.71 662-678 18.3 5.1813% $ 206.79 $ 10.71 648-662 14.1 6.6225% $ 161.79 $ 10.71 631-648 10.8 8.4746% $ 126.43 $ 10.71 608-631 7.9 11.2360% $ 95.36 $ 10.71 581-608 5.5 15.3846% $ 69.65 $ 10.71 542-581 3.5 22.2222% $ 48.22 $ 10.71 300-542 1.5 40.0000% $ 26.79 $ 10.71 In this manner, the output is now set credit limits per band so that we have achieved constant dollars at risk across bands. Now in practice it’s unlikely that a lender will grant $1,683.27 for the 763 to 777 credit score band but this exercise illustrates how the numbers are generated. More likely, a lender will use steps of $100 or something similar to make the credit limits seem more logical to borrowers. What I like about this constant dollars at risk approach is that we aren’t really favoring any particular credit score band. Credit limits are simply set in a manner that sets dollars at risk consistently across bands. One final thought on this: Actual observations of delinquencies (not just predicted by the scores odds table) could be gathered and used to generate a new odds tables per score band. From there, the new delinquency rate could be generated based on actuals. Though, if this is done, the duration of the sample must be long enough and comprehensive enough to include both good and bad observations so that the delinquency calculation is robust as small changes in observations can affect the final results. Since the real world does not always meet our expectations, it might also be necessary to “smooth” the odds-chart so that its looks appropriate.
Learn More Image
