The Question Before the RFP

On the difference between procuring a solution and understanding a field, and why the two are routinely confused.

A head of payments at a mid-sized bank issues an RFP for a fraud detection platform. The document is forty-three pages, the requirements list runs to two hundred and eleven items, and twenty-three vendors are invited to respond. Four months later, eleven responses arrive, the evaluation grid is built, the shortlist is drawn, and a vendor is selected. Six months after that, the implementation is underway and the team begins to notice that the chosen platform, while perfectly capable on every requirement listed in the RFP, is solving a slightly older version of the problem than the one the bank is now trying to address. The technology has moved. The requirements, frozen on the day the RFP was issued, did not.

This is not a story about a bad RFP. The document was thorough, the process was fair, and the chosen vendor is competent. It is a story about using the right tool for the wrong question.

The RFP is one of the most disciplined instruments a financial institution has. It forces internal clarity, it documents decisions, it produces comparable responses, and it withstands audit. For known categories with mature markets, where the institution already understands the question it is asking and the answer it is looking for, the RFP is hard to beat.

For the question that comes earlier, the question of what is even worth asking about, the RFP is the wrong instrument. And that earlier question, in 2026, is increasingly the one that determines whether a transformation programme actually delivers.

What the RFP does well

It is worth listing this honestly, because the temptation in any comparison is to dismiss the format being compared against. The RFP, used for what it is built for, does several things that no lighter format can replicate.

It produces a defensible decision. In regulated environments, the ability to show a clear, documented, comparative process is not optional. The RFP delivers that.

It enforces internal clarity. Writing a requirements document forces a team to articulate what it actually wants, often surfacing internal disagreements that had been quietly unresolved.

It creates comparability. Eleven responses to the same questions, evaluated against the same criteria, give an institution a structured view of the market that is hard to assemble any other way.

It includes the non-functional dimensions that genuinely matter. Security, financial stability, regulatory compliance, references, support model, contractual terms. These cannot be assessed in a sixty-minute conversation, and the RFP is the right place to assess them.

For a category the institution already understands, with vendors that already exist in a mature market, this is exactly what is needed.

What the RFP cannot do

The cost of using the RFP outside its proper range is less visible, and therefore more often paid.

The RFP cannot tell you what you do not know to ask about. A requirements document captures the institution's current understanding of the problem. It cannot capture what is missing from that understanding. If the team writing the document does not know that agentic compliance has fundamentally changed the architecture choices in the category, the RFP will not surface that knowledge. The chosen vendor will solve the problem the team thought it had, not the problem it actually has.

The RFP excludes the most innovative responses. Preparing a serious RFP response costs a vendor between fifteen thousand and one hundred thousand euros in time and effort. Established vendors with dedicated bid teams can absorb that cost. Newer entrants, often the ones whose work is most worth knowing about, frequently cannot. The format quietly filters out the responses that would have been most informative.

The RFP hardens vendor language. A response prepared for a procurement process is structured for the procurement process. The hedging, the qualification, the careful positioning, all of these protect the vendor from the scoring grid. The conversation that would have produced a clearer view of what the technology actually does, and where it does not yet work, is precisely the conversation the format does not allow.

The RFP freezes requirements at issue date. A category that is moving quickly will move further during the four to six months a typical RFP runs. The institution evaluates against requirements that are already aging. By the time the contract is signed, the field has shifted, and the chosen solution is solving last year's problem.

The RFP confuses curiosity with procurement. Some institutions issue RFPs primarily to understand a market rather than to procure a solution. Vendors have noticed. The responses now arrive shaped by the assumption of imminent purchase, the language is hardened, and the comparative learning that was supposed to emerge from the exercise rarely does. The institution pays the cost of running an RFP and gets neither a clean procurement outcome nor a clear understanding of the field.

A different tool for a different question

The discovery call is built for the question the RFP cannot answer. Not "who is the best vendor in this category", but "what is actually moving in this area, what should we be paying attention to, and what does the next eighteen months look like for a team like ours."

The format is small by design. Sixty minutes. A theme set by the institution, not by an organiser. A handful of innovators selected for relevance to that theme, plus, where useful, peers from non-competing institutions in different markets. The conversation is editorial in posture, not commercial. Innovators present in service of the question, not in service of a sale. There is no scoring grid, no requirements list, and no obligation to take the conversation further than the hour itself.

What that produces is a different kind of output. Not a comparable response across vendors. Not a defensible procurement trail. Something more useful at a different stage: a working view of the field, sharp enough to inform the decisions that come next, including, where appropriate, the decision to issue an RFP and what that RFP should actually ask.

A side-by-side view

Laid out plainly, not to argue that one replaces the other, but to make explicit which one does what.

Dimension	The RFP	The discovery call
Question it answers	Who is the best vendor in this category	What is moving in this field, and what should we be looking at
Time commitment	Four to six months, often longer	Sixty minutes
Cost to the institution	Significant, in time and process overhead	Minimal
Cost to the responding party	Fifteen to one hundred thousand euros per serious response	A prepared, structured conversation
Who participates	Vendors with the resources to respond	Innovators selected on merit, regardless of size
Posture in the room	Sales, hardened by the procurement context	Editorial, question-led
Output for the team	A defensible, comparable shortlist	A working view of the field
Treatment of the unknown	The format cannot surface what is not asked	The format is built to surface what was not yet asked
Useful when	The category is known and the question is settled	The category is moving and the question is still forming

The two formats answer different questions. A senior team that uses the RFP to do the job of the discovery call will be expensive and slow. A senior team that uses the discovery call to do the job of the RFP will lack the procurement discipline a regulated environment requires. The work is to use each for what it actually delivers.

The sequencing question

The most useful way to think about the two formats is sequentially.

The discovery call belongs before the RFP. It is the format that helps a team understand whether an RFP is the right next step at all, and if it is, what the RFP should actually ask. A discovery call run six weeks before issuing an RFP will frequently change the requirements list in ways that materially improve the outcome. It will surface vendors that would never have made the invitation list. It will reveal that the question the team thought it was asking has already been overtaken by a sharper version of the same question.

The RFP belongs after. Once the team has resolved its understanding of the field, knows the question it actually wants to ask, and is confident the category is mature enough to procure against, the RFP does its job well. It is a procurement tool, not a learning tool, and treating it as a procurement tool keeps it sharp.

The institutions that get this right do not run fewer RFPs. They run better ones, against clearer questions, with the right innovators in the response set, after the discovery work has already been done.

Why this matters now

The agenda for 2026 inside most financial institutions is dense with categories that are still in motion. Agentic systems, programmable payments, the maturing crypto and stablecoin environment, the next wave of regulatory implementation, the continuing reshaping of distribution. Each of these will at some point require a procurement decision. None of them is yet stable enough that the procurement decision can be made cleanly without the discovery work first.

The institutions that arrive at those procurement decisions with a clear, current view of the field will write better RFPs, attract better responses, and end up with better outcomes. The institutions that skip the discovery step will do the work the hard way, in the form of expensive contracts that solve last year's version of the problem.

The question is not whether to run an RFP. It is whether the team has done the hour of discovery that should come before it.