The RFP should expose delivery assumptions
A proposal can describe a target platform without demonstrating a workable route from the current estate. Financial services buyers need to evaluate source data, downstream consumers, operating constraints and the responsibilities that remain with the institution.
Henna83 recommends an RFP built around proof: a bounded problem, agreed current-state description, mandatory control requirements, a common demonstration scenario and a transparent commercial model. Ask providers to respond to the same constraints.
Three choices shape selection: mandatory capabilities, evidence that establishes them, and delivery assumptions the buyer will accept. Weighted scores compare qualified proposals. They should not let an impressive presentation offset a failed mandatory requirement.
Include the business sponsor, architecture, data, operations, security, third-party risk, procurement and finance. Their questions differ, but the decision must be coherent. An award should reflect both the proposed outcome and the institution's ability to support delivery.
Select against demonstrated delivery conditions, not an attractive future-state diagram alone.
Risk management shapes the buying process
The 2023 interagency guidance addresses risk across the third-party relationship lifecycle [1]. The bank determines due diligence, contract provisions and monitoring appropriate to the activity and risk. Selecting a provider does not eliminate those responsibilities.
AWS readiness guidance spans six perspectives [2]. That breadth helps assess people, governance, security and operations alongside migration. The institution's requirements remain the evaluation basis.
McKinsey's estimate of bank data spending at 6-12% of annual technology budgets [3] provides investment context. It is not a procurement saving target or proof that the lowest fee creates the best value.
Compare the same scope, client effort, transition assumptions, acceptance evidence and run-state costs. A fee that excludes reconciliation or vendor coordination may move costs to the buyer. Conversely, a broad included-service label does not prove useful deliverables.
Make excluded work and client dependencies visible before comparing price.
Six questions that reveal proposal quality
Which current-state assumptions drive architecture? Require sources, record formats, volumes, interfaces and unknowns. Ask what would change scope or price.
How is migrated meaning proven? Request conversion and reconciliation covering important events, field-level differences and consumer acceptance.
Who coordinates vendors and consumers? Require responsibilities, expected client effort and interface approval. Delivery extends beyond the provider's own backlog.
Who will actually deliver? Evaluate named roles, availability, relevant experience and replacement arrangements. Distinguish committed resources from representative resumes.
What is ready at handoff? Examine monitoring, recovery, documentation, knowledge transfer and support. Understand what the institution will operate.
How is change controlled? Request a process for validating changed assumptions, estimating impacts and authorizing work. Evaluate how the model handles a client decision delay as well as a provider defect.
Evaluation context: mandatory requirements should be traceable to a business or control need. Excessive generic requirements can obscure the decisive ones. For each scored criterion, state what a score of zero, partial evidence and full evidence means. Test a sample proposal with the evaluators before formal scoring. Confirm that the same facts produce comparable scores and that narrative concerns survive the numerical roll-up.
Exhibit: gated, weighted evaluation
Apply mandatory gates before weighted scoring. The kit provides an editable example. The weights below are illustrative, not an industry standard. Score 0-5 against retained evidence.
| Criterion | Example weight | Evidence |
|---|---|---|
| Architecture/integration fit | 25% | Assumptions and interface plan |
| Data and acceptance | 20% | Mapping and reconciliation design |
| Team and delivery plan | 20% | Named roles and dependencies |
| Controls and handoff | 20% | Risk response and support plan |
| Commercial transparency | 15% | Comparable scope, rates, exclusions |
Using the scorecard: review gates first, then weighted criteria. Require evidence notes and an unresolved-assumption log. The example model normalizes weights to 100%; it must reject incomplete scores rather than treat them as zero. A failed gate excludes the option until the buyer formally changes the requirement or resolves the failure. Retain both the score and the decision rationale.
Buyer-defined gates may include security/access, critical interface fit and acceptable data handling. A failed gate cannot be averaged away.
Worked example: different proposal boundaries
Illustrative scenario, not a vendor ranking. Provider A offers a lower fixed fee for ingestion. Provider B includes mapping, business reconciliation and a defined handoff at a higher price.
The buyer normalizes scope and estimates the client effort and specialist cost needed for A's exclusions. It checks whether B's included work has clear deliverables and acceptance. Both providers receive the same scenario: a late file, a reversed transaction and a vendor with a fixed cutoff.
Each explains how it detects, resolves and communicates the issue. Evaluators record evidence and unknown assumptions. Fluent answers without artifacts receive no automatic credit.
The selection compares qualified options against delivery priorities and the full cost boundary. The least expensive comparable option may win. A higher fee may be justified by demonstrated scope or reduced buyer burden. The decision record should explain the tradeoff.
Before contracting, the team tests whether the preferred model requires client capacity that is actually available. An otherwise strong proposal can fail when its business acceptance or source remediation dependencies are unstaffed.
Questions for procurement and the CIO: Are scopes comparable? Is the named team available? Who owns reconciliation? What client effort is required? Which exclusion creates a delivery gap? What would trigger additional fees?
Prepare a defensible decision record
Define the problem, current-state boundary and mandatory requirements. Identify unknowns to validate during discovery. Agree weights before reviewing proposals.
Use a common demonstration script and evidence register. Let technical, operating, risk and commercial evaluators record findings, then resolve conflicts jointly.
Before award, confirm availability, assumptions, client responsibilities, deliverables, acceptance, support and change control. Retain selection reasons and accepted risks. Establish ongoing monitoring appropriate to the relationship.
The Vendor RFP Assessment Kit includes requirements, scoring, demonstration and decision templates. Henna83 structures buying decisions, normalizes proposals and connects commercial choices to integrated delivery. Request executive advisory to review a consequential sourcing decision.
Measurement detail: record complete evaluation coverage, unresolved assumptions and gate status. Track selection cycle time only alongside evidence quality. A quick award without resolved critical dependencies may simply defer the decision into delivery.
References
[1] Federal Reserve, FDIC and OCC. Interagency Guidance on Third-Party Relationships: Risk Management. June 6, 2023. https://www.federalreserve.gov/frrs/guidance/interagency-guidance-on-third-party-relationships.htm
[2] Amazon Web Services. Evaluating migration readiness. Living technical documentation; accessed October 10, 2026. https://docs.aws.amazon.com/prescriptive-guidance/latest/evaluating-migration-readiness/introduction.html
[3] McKinsey & Company. Next-gen banking success starts with the right data architecture. February 28, 2025. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-forward/next-gen-banking-success-starts-with-the-right-data-architecture