Parts 1 and 2 covered the human forces that tilt a purchase before the paperwork starts. The natural objection: that is exactly why we run a structured process, to take the bias out. It would, if the machinery worked the way buyers believe. The structured half is where the professional has the most practiced advantage, because the buyer assumes it is neutral and the seller knows it is not.

The RFP: Often a Document the Incumbent Helped Write

The RFP is supposed to be the equalizer. In practice it is frequently the most rigged artifact in the process, not from corruption, but because requirements have to come from somewhere, usually the vendor the buyer knows best. Procurement people will tell you privately that it is common for a preferred vendor to shape the requirements before the RFP goes out, sometimes until the specs read off one competitor's data sheet. The "fair" process then confirms a conclusion the requirements pre-loaded. That is why challengers who arrive only at the RFP stage win 1% to 5% of the time while incumbents win 80% to 90% — the gap is requirement authorship, not product. It also produces "column fodder": the second and third bids solicited only to satisfy a three-bid rule. If you have watched a vendor go quiet mid-process, their forecast flagged your deal as fodder, and they were right.

The fix is not glamorous. Write your requirements from your own needs — operational pain, customer experience, integration realities, risk posture — and weigh them before you see a single response. A scorecard built after the demos is a justification; one built before is a control. This matters double for a de novo, where there is no incumbent to author the requirements, which sounds like an advantage until the vacuum gets filled by whichever vendor the founders already know. A clean sheet does not write its own spec.

This is how we build RFPs at CCG Catalyst: each one is driven by the client's own requirements and is unique to that institution — a copy-and-paste of the last engagement is not a given. We also lean toward an instrument weighted to yes/no questions. "Do you do this today, in production — yes or no?" is far more precise than "describe your capabilities," which invites a paragraph of marketing. Binary answers are comparable across vendors, harder to dodge, and easy to verify against the demo and the reference calls. And invite more vendors, not fewer. A requirements-driven RFP is a screening instrument, and the wider the field you put through it, the harder it works for you — surfacing options you would not have shortlisted on reputation alone and narrowing the list to genuine fits before you spend a minute in a room. Let the RFP do that work.

Two disciplines make those requirements worth the paper. First, write them for today and for tomorrow. A bank does not buy technology for the institution it is now; it buys for the one it intends to become — the products on the roadmap, the volume it expects, the rails and channels it will need three to five years out. Requirements anchored only to current-state operations lock in a platform you will outgrow before the contract does.

Second, separate business requirements from functional requirements, and keep them in their own lanes. A business requirement is the outcome the institution needs; a functional requirement is the specific capability the system must perform to deliver it. For example, the business requirement might be: "Within twelve months we will offer commercial real-time payments and let treasury clients initiate them through digital banking." The matching functional requirements are concrete and testable — the platform must originate and receive FedNow and RTP transactions, expose them in the commercial digital channel and through an API, enforce dual approval and per-user limits, and post to the core in real time. The business requirement tells the vendor what you are trying to accomplish; the functional requirements are what you actually score and demo against. Blur the two and you get proposals that answer the vision while quietly dodging the mechanics.

Scoring: Weighting Is Where the Decision Lives

The scorecard lends an aura of objectivity the underlying judgment has not earned; every "8 out of 10" is an opinion wearing a number. Integrity lives in two places buyers underinvest in: the weights, and who scores. Weights set before responses arrive, owned by the business rather than whoever is friendliest with a vendor, separate a scorecard that disciplines the decision from one that launders a preference. If the weighting can move after the demos — and it usually can — the scorecard is theater with arithmetic.

The deeper error is confusing the demo score with delivery probability: a vendor can score brilliantly on a capability they have built but rarely deployed at your size. The capability is real; the risk is unscored. The most useful column most bank scorecards lack is not a feature — it is "evidence this works at a bank like ours," scored from references and documented go-live dates. Vision is cheap to score and expensive to buy.

The Demo: A Rehearsed Performance

The demo is the most enjoyable part of the process and the least informative, because it is theater — the vendor controls the script, the sequence, and the data. Practitioners are candid that most demos are glorified sales presentations that glide through clean processes with sample data from a fictional company that behaves perfectly and looks nothing like your business. Everything works because it was built to work in that exact order. The tell is rigidity: a vendor who insists on a canned walk-through often needs the safety of the prepared path.

Take the script away. Give every finalist the same scenarios built from your own transactions and ugly exceptions — the disputed transaction across two products, the loan modified mid-stream, the month-end that never quite ties — and make them run yours, live, in an order you choose. The vendor who names a limitation and works the problem is showing you their implementation behavior; the one who deflects back to the slide is showing you the next several years. Watch for two staging moves, too: "stacking the room" with senior faces and the occasional planted enthusiast to manufacture momentum, and on the site visit, "divide and conquer," splitting your committee so no one hears the same answer twice. The defense for both is the same — keep your committee together, compare notes relentlessly, and write down who told you what.

Stage the demo, too. A first demo has exactly one job: does the solution meet your requirements and deliver the functionality you wrote down? Keep it there. When a vendor opens an initial demo by talking up implementation, professional services, and onboarding, that is a sales move, not an evaluation — and a waste of your time. Technology architecture, training, implementation, and integration discussions belong with the two or three finalists, once fit is established. If a vendor cannot demonstrate the requirements in that first session — if the functionality is not there — there is no reason to go further. You are done; move on.

Run the Process You Think You're Running

The front end of the process is not neutral. The RFP often scores a document the preferred vendor helped write; the scorecard launders judgment unless the weights are locked first; the demo is a rehearsal on someone else's data. Run the process you think you are running: invite a wide field and let the RFP screen it, write and weight your own requirements before you watch, make the vendors demo your transactions rather than their script, and judge the first pass on requirements alone — implementation and professional-services discussion can wait for the finalists.

Part 4 finishes the machinery — references, the contract, implementation, and the advisor you hired to keep you safe.

CCG Catalyst advises community and regional banks, credit unions, fintech companies, and de novo founders on technology strategy, vendor selection, RFP design, and contract negotiation. If your institution is preparing for a core, digital, payments, or fraud decision — or building one from scratch — reach out to our team at www.ccgcatalyst.com. For related reading, see the full library at CCG Insights.

See our latest announcement: CCG Catalyst's Paul Schaus Named a 2026 Top Consultant by Consulting Magazine

By: Paul Schaus | Founder & Managing Partner, CCG Catalyst Consulting

Disclaimer: The views expressed in this article represent the perspective of CCG Catalyst Consulting based on our direct experience advising financial institutions. This commentary is intended to stimulate industry discussion and does not constitute legal, accounting, or regulatory advice.