How does a bank evaluate a technology vendor?

The third-party relationship lifecycle, from planning and due diligence to monitoring and exit.

By Vendito Tech · Published September 29, 2026 · Financial institutions
READING MAP

A short answer, the workflow, an illustrative example, and links to primary sources.

PlanSelectContractMonitor and exit

THE SHORT ANSWER

A vendor review is about the activity the vendor will support and the risk that activity creates. Federal banking agencies describe a lifecycle of planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination. The depth of review should fit the relationship's risk and criticality.

The bank owns the relationship

A vendor may supply software, data, operations, or specialist services. The bank still needs to understand how the service affects its customers and its own obligations. It starts by defining the business purpose, expected benefit, data and system access, dependencies, and a person responsible for the relationship.

The joint banking-agency guidance says practices should be proportionate to the bank's size, complexity, risk profile, and the criticality of the activity. A small, low-impact tool and a service central to customer transactions should not receive identical treatment.

What review and contracting look for

Due diligence may examine a provider's ability to deliver, information security, resilience, financial condition, use of subcontractors, and legal or compliance concerns relevant to the service. Contracting turns important expectations into responsibilities: access, reporting, incident handling, service levels, records, and what happens when the relationship ends. The exact requirements depend on the activity and agreement.

Review is not complete at signing. Ongoing monitoring checks whether the service and its risks have changed. Exit planning matters because data, integrations, and operational knowledge must move or be retired without losing control of the underlying work.

A product design implication

Make the evidence trail easy to retrieve. The useful system shows what was requested, what was reviewed, who accepted a risk, what changed, and when another review is due. It should also distinguish a missing document from an affirmative approval.

A concrete example

Illustrative example: a bank considers a document-processing provider. A demo may prove extraction quality. The bank still needs to understand data retention, access, downstream corrections, service continuity, and how its staff can inspect and override a result.

Original sources

The process explanations above are educational summaries. The linked primary sources govern their own terms and can change; check them for current requirements.

Working through a complex system?

I help teams connect product decisions, engineering, and operating reality.

Book a 30-minute call