The Request for Proposal has been the backbone of technology selection in specialty finance for decades. It promises rigour, comparability and an audit trail. Yet ask the people who run these processes today, on either side of the table, and a consensus emerges quickly: the traditional RFP is broken. What is less obvious is what should replace it.
That question has occupied the Finativ Technology & Innovation Forum, run in association with Finance Connect, across three sessions this year. It first surfaced during a discussion on AI, where a debate about point solutions, platforms and embedded technology turned into a wider argument about how lenders select systems at all. It continued in person with vendors in the room, and concluded with a lender-only session designed to draw out some principles. This article sets out what we learned.
The classic RFP is a spreadsheet of hundreds, sometimes thousands, of questions sent to a long list of vendors, with the responses scored and ranked. The trouble is that it tells buyers almost nothing. Ask "does your system handle indexation?" and the answer will be "yes". Every answer will be "yes". As one forum participant observed, vendors can now push the entire questionnaire through AI, so all the exercise really tests is their ability to answer a questionnaire.
This is not an argument against rigour. It is an argument against a format that rewards the appearance of rigour while producing no genuine insight into whether a system will work in your business, with your data, alongside your people.
Scale and impact remain the answer. A multi-million pound decision that touches the whole business warrants a structured, defensible process with multiple candidates evaluated on consistent criteria. Below that threshold, the calculation changes. For lower-value purchases on shorter contracts, lighter-touch due diligence, reference checks and trusted recommendations may serve better, accepting some risk in exchange for speed. If the worst outcome is a lesson learned and an exit after twelve months, a six-month selection process costs more than the mistake it exists to prevent.
There is a counterpoint worth stating, though. In recent live selection processes we have been involved in, a structured go-to-market exercise twice produced an unexpected winner: a more innovative solution that was not on anyone's radar, where the usual suspect lost. Run with an open mind, the process retains real value as a discovery mechanism. The market moves quickly, and the vendor you already know is not always the vendor you need.
If there was one structural recommendation from the forum, it was this. Spend less effort on the exhaustive desktop exercise and get quickly to two or three credible candidates. Then invest the time you have saved in live demonstrations, scenario challenges and genuine proofs of concept built around your killer requirements, the handful of things the system absolutely must do for your business specifically.
Just as important is who you meet. The salesperson is likely to have a tendency to say yes to everything. Buyers should insist on time with the architects, consultants and delivery people they would actually work with. One live example from the forum made the point neatly: a vendor was asked to demonstrate a specific product structure in a live session. The vendor could not do it. That single exchange delivered more useful information than a thousand scored questionnaire responses.
Integration has moved from an implementation detail to a primary selection question. Several forum participants, particularly those operating within larger group or shared-services IT environments, described engaging their technology teams far earlier in the process, because proving that a solution fits the existing architecture has become the dominant consideration.
This connects to a wider architectural trade-off. A single vendor that does everything adequately is easier to manage than a dozen best-of-breed vendors doing things brilliantly, but it rarely does anything brilliantly itself. The forum's view was that a modular, composable stack is manageable provided buyers standardise on common integrations rather than customising every connection. Heavy customisation costs twice: once to build, and again every time anything changes. Participants also flagged a sharper commercial edge to this, with some vendors charging for bespoke work up front and then adding an ongoing percentage to maintenance fees, even where the customisation becomes part of the product sold to other clients. Contemporary selection processes should surface these practices before signature, not after.
Perhaps the strongest sentiment of the whole discussion - a vendor with slightly weaker technology but a genuine appetite to collaborate beats a technically superior vendor that is difficult to work with. Products can be improved together but a relationship cannot be retrofitted.
The difficulty is that culture does not show up in a questionnaire. It shows up in how a vendor responds when challenged in a live session, whether they will put their delivery people in the room, and how they behave when asked to demonstrate something they cannot do. An honest "no, we can't do that" is worth more than a confident "yes" that unravels during implementation. Designing the selection process to expose these moments is precisely what the modern approach should do.
Asked which critical consideration is most often missing from an RFP, the forum's answer was clear: the organisation's own readiness for change. Change management, not technology, is what kills projects. Code can be fixed. People who never wanted the change cannot be forced to make it work.
That places demands on the buyer that no vendor can satisfy. The case for change must be realistic, because inflated expectations guarantee disappointment and hand ammunition to resistance. The business must be a genuine author of the requirements, not a recipient of them, and must accept that its own processes may need to change to get the best from a new system. And the organisation should be alert to "shiny object" purchases driven by what a competitor has rather than what the business needs. The first question is never "which system?" It is "why are we doing this, and is everyone bought in?"
Even a well-run selection process is an assessment, not a final answer. Much of the real learning happens during implementation, and that should be built into timelines, budgets and expectations from the start rather than treated as a failure of the process. Decision-makers who over-egg what an RFP can tell them set their projects up for disappointment before a contract is signed.
Independent facilitation helps here too. A process run by someone who starts with a bias will end where the bias pointed, whatever the scores say. An external party can keep the evaluation impartial while the buyer's own relationships and instincts, which matter, are tested rather than simply trusted.
The forum concluded, only half in jest, that the process may need a new name altogether. Whatever we call it, the shape is becoming clear. It is proportionate to the scale and impact of the decision. It moves quickly to a short list and then goes deep, with live scenarios rather than scored spreadsheets. It tests the vendor's people and culture as deliberately as it tests the product. It treats fit with the existing architecture as a first-order question. And before any of that, it asks whether the business itself is ready to change, because no selection process can rescue a project the organisation never truly wanted.
The Technology & Innovation Forum brings together senior technology and operations leaders from across specialty finance for candid, off-the-record discussions. If you would like to join a future session, or to talk about how Finativ supports technology selection, get in touch.
