Tag: RFI

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.