BaaS vendor evaluation. What the standard checklist misses.

Most BaaS vendor evaluations focus on the wrong things. The buyer asks for the feature list, the compliance certifications, the reference logos. These are necessary but not sufficient. The things that actually determine whether a vendor relationship works at production scale, eighteen months in, are not on the standard RFP.

I have been on both sides of these conversations: I have evaluated vendors as a buyer, and I now run a vendor that responds to buyer RFPs. The questions that should be on the buyer’s evaluation list are not the questions that are typically asked.

Five questions that matter more than they look on a comparison sheet, and the answers that separate vendors that can execute from vendors that can pitch.

Provider switchability

The vendor’s stated capability “we integrate with multiple banking partners” is technically true and operationally meaningless if the integration takes nine months and requires custom development per partner. The right question is more specific.

What is the elapsed time to switch from Banking Partner A to Banking Partner B for an existing client? Ask for the most recent provider switch the vendor has executed, with the specific elapsed time and the client industry. If the answer is more than twelve weeks, the multi-provider claim is marketing copy. If the vendor cannot name a recent switch, they have not done one - which means the claim is theoretical.

Provider switchability matters because banking partner relationships fail. They get acquired, change strategy, exit your market, or simply become operationally unworkable. A vendor that cannot switch its clients between providers is a vendor that hands you the same risk you were trying to outsource by buying a platform.

Production incident handling

The vendor’s stated SLA on uptime tells you nothing about what happens when something breaks. SLAs are contractual commitments measured monthly. Real incident response is measured in minutes, and the difference between a vendor that handles incidents well and one that does not is not visible until you are inside one.

The right questions are operational, not contractual. Who in the vendor’s organisation gets the page when a production incident hits at 2am? What is the median time-to-acknowledgement? How is the buyer kept informed during the incident? What is the post-incident communication discipline: do you get a written post-mortem, and within what window?

Vendors that cannot answer these crisply are running incident response ad-hoc - which is fine until it is not. Ask to see a post-mortem document from a recent production incident. Vendors with mature incident discipline will have one, redacted appropriately. Vendors without it will offer reasons why they cannot share, which is the answer.

PS budget reality and total cost normalisation

Professional services budget in year one typically runs 30 to 50% of annual licence cost. This is the number most buyer evaluations skip, because the headline comparison sheet shows licence rate but not PS spend. The buyer signs the cheaper licence, then spends 70% more than expected on PS, then ends year one with a total cost that exceeds the more expensive vendor they passed on.

The right question is: what was your actual PS spend, in year one, for the three most recent comparable clients? Ask for the absolute numbers, not the ratios. A vendor that quotes you a low licence rate and a “typical” PS engagement of €40k may be averaging €90k in actual delivery, with the gap absorbed by client frustration rather than scope renegotiation.

Normalise total year-one cost across vendors at the actual PS reality, not the headline rate. The cheaper vendor often becomes the more expensive vendor once the PS budget catches up with the integration complexity. The standard PS rate corridor for credible white-label fintech vendors is €100 to €130 per hour. Below that range, something is being hidden. Above it, something needs to justify the premium.

Roadmap influence vs roadmap promises

Every vendor will commit to features in the contract. The question is whether the buyer’s specific needs influence the actual roadmap, or just appear in a contractual schedule that is honoured technically but not operationally.

The right question: show me the last three product features that were prioritised because of customer requests, and identify which customers requested them. Vendors with a real customer-influenced roadmap can name names and dates. Vendors that cannot are running the roadmap from internal priorities and the contractual commitments are calendar promises - not strategic priorities.

This distinction matters because every regulated fintech eventually needs a feature that is not on the platform today. The vendor that treats your need as a roadmap input will ship it on a credible timeline. The vendor that treats it as a contractual obligation will ship a minimum version on the deadline, with edge cases unaddressed, and the next iteration deferred indefinitely.

Termination economics

What happens to the buyer’s data, configurations, and customer state if the relationship ends. This is the question buyers most often skip during evaluation, and the question most often regretted later.

The specific items to evaluate: the immediate practical question (how do we extract our data, in what format, with what completeness), the contractual exit period (and whether it is in months or years), the data migration support obligations (does the vendor help with the off-boarding, or is it your problem), and the off-boarding cost (some vendors charge significant fees for data extraction and migration support).

Vendors that bury these questions in legal terms know what they are doing. They are protecting their renewal economics by making the cost of leaving high enough to bias the renewal decision in their favour. Buyers should treat the termination clauses as essential commercial terms, not as legal boilerplate. The honest vendor is the one that makes leaving operationally clean, because they are betting on renewal being a continuation of value rather than a function of switching cost.

What the standard checklist gets right

The standard vendor evaluation criteria (features, integrations, compliance certifications, reference logos) are necessary baseline checks. They are not sufficient because vendors invest in passing those checks. SOC 2 reports, ISO 27001 certifications, PSD2 compliance attestations are real signals of operational maturity. Reference customers are real signals of execution capability. Feature checklists capture meaningful platform scope.

The five questions above are harder for vendors to game because they require specific operational answers, not certifications or marketing claims. Vendors that can answer them crisply are vendors that have lived through the situations the questions describe. Vendors that cannot are vendors that have not yet, which is information.

The conversation that produces good outcomes

The vendor evaluation conversation that produces good outcomes is the one where the buyer is asking these questions and the vendor is answering them directly, with specific names, dates, and numbers. The conversations that produce bad outcomes are the ones where the buyer is asking the standard questions and the vendor is meeting the standard answers. The standard is too low.

A vendor that responds to these questions defensively, or that asks why the buyer needs that level of specificity, is a vendor that is not used to being evaluated at this depth. That is information about the vendor. A vendor that welcomes the questions and answers them with the operational detail they imply is a vendor with the discipline that production-scale relationships require. That is information too.

The buyer who asks these questions during evaluation - rather than discovering them through operational pain in year two - is the buyer who signs the right contract.