Vendor Management for Banks: Third-Party Risk Assessment Guide
7/5/2026
This post covers the vendor management program as a discipline. Two companion pieces handle specific slices: our post on fintech partnerships addresses arrangements where a third party stands between the bank and the customer, and the cybersecurity post covers vendor information security specifically.
The governing premise, stated in supervisory guidance and worth repeating because institutions keep acting otherwise: using a third party does not diminish the bank's responsibility to perform the activity safely, soundly, and in compliance with law. The vendor does the work. The bank owns the outcome.
The Framework
The federal banking agencies issued interagency guidance on third-party relationships in June 2023, replacing the agencies' prior individual guidance. It frames a risk-based lifecycle:
Planning — deciding what the institution needs and what risk the arrangement introduces, before selecting anyone.
Due diligence and selection — assessing candidates proportionate to the risk.
Contract negotiation — securing the rights the institution will need.
Ongoing monitoring — through the life of the relationship.
Termination — planned rather than improvised.
With governance, documentation, and independent review running throughout.
One important scope point: the guidance applies to third-party relationships generally, not only to those an institution labels critical. Tiering determines the depth of the work, not whether the relationship is in the program.
Criticality Tiering
Tiering is where most programs either become useful or become a spreadsheet.
The question is not how much the institution spends with the vendor. It is what happens if the vendor fails or performs badly. Factors that drive a relationship to a higher tier:
- It supports a critical activity — a significant bank function, shared service, or something whose failure would materially disrupt operations
- It handles customer information
- It touches compliance obligations the bank must meet
- It has access to bank systems or networks
- It is customer-facing, so its conduct is attributed to the bank
- Substitution is difficult — few alternatives, long conversion time, or proprietary data
- It processes money movement
A small-dollar vendor with network access and customer data is a higher tier than a large-dollar vendor supplying office furniture. Programs that tier by spend get this backwards, and it is the most common structural error.
Tiering should be revisited, because usage grows. A vendor onboarded for a pilot that now supports a core process needs re-tiering, and nothing prompts that unless someone owns it.
Due Diligence Scaled to Tier
For higher-tier relationships, the scope should cover:
Financial condition — genuinely assessed, not just requested. Several notable third-party failures in recent years were solvency events, and the institution that reads the financials has warning the others do not.
Business experience and reputation, including litigation and regulatory history of the firm and its principals.
Risk management and control environment, evidenced through an independent assurance report where one exists — a SOC 1 for financial reporting relevance, a SOC 2 Type II for security and availability. Type II matters: Type I reports on design at a point in time, Type II on operating effectiveness over a period.
Information security, including how customer data is handled, encrypted, and segregated.
Business continuity and resilience, with evidence of testing rather than a plan document.
Subcontractor reliance — who else is in the chain.
Insurance coverage and limits.
Compliance capability where the vendor performs a regulated activity on the institution's behalf.
Country risk for offshore providers.
The proportionality point deserves emphasis in both directions: the same package for every vendor is either wasteful or inadequate, and institutions frequently do both — over-diligencing the janitorial contract and under-diligencing the loan origination system.
Reading Assurance Reports
Collecting a SOC 2 and filing it is not diligence, and it is what most institutions do.
Four things to actually look at:
Scope. Does the report cover the service the institution uses, at the locations it uses, for the period in question? Reports frequently exclude the specific module or region that matters.
Exceptions. The testing results section lists control failures the auditor found. Read them and assess whether they affect the institution's use.
Complementary user entity controls. Nearly every report includes a list of controls the customer must perform for the vendor's controls to be effective. This is the section institutions never read, and it is the section that assigns them work.
The period covered. A report ending fourteen months ago provides limited assurance about now, and a bridge letter is the normal remedy.
Contract Terms
The rights the institution will need are the ones it must negotiate before signing, because afterward it has no leverage.
- Clear scope and performance standards with measurable service levels
- Audit rights for the institution, and access for its regulators
- Information security and confidentiality obligations
- Incident notification with specific timeframes, not "promptly"
- Subcontractor disclosure and approval, with flow-down of material obligations
- Business continuity commitments and evidence of testing
- Data ownership, portability, return, and destruction on exit
- Limitation of liability that is not illusory relative to the potential harm
- Insurance requirements
- Compliance obligations where the vendor performs a regulated activity
- Termination rights, including for regulatory reasons
- Termination assistance — the term institutions most regret omitting
Ongoing Monitoring
The characteristic program failure: thorough at onboarding, dormant afterward.
Monitoring for a higher-tier vendor should cover performance against service levels, refreshed financials, current assurance reports with exceptions reviewed, incident history, changes in subcontractors or ownership, and any regulatory action. Frequency scales with tier; annual is the practical floor for critical relationships.
Two additions that materially improve a program. Business owner attestation — the person who uses the vendor confirms annually that performance is acceptable and nothing material has changed, which surfaces problems the vendor manager cannot see. And monitoring the relationship's growth, since scope creep is how a low-tier vendor becomes a critical dependency unnoticed.
Fourth-Party and Concentration Risk
Fourth-party risk is the vendor's own supply chain — the cloud provider behind the software, the offshore developer, the data center. The institution cannot contract with them directly, so the controls are contractual disclosure, flow-down requirements, and assurance that the vendor manages its own chain.
Concentration hides here specifically. Several apparently unrelated vendors may depend on the same underlying provider, so an outage the institution modeled as affecting one system affects four. Mapping critical vendors to their underlying infrastructure is unglamorous and is the only way to see it.
Concentration also runs the other way: a vendor for whom the institution is a large share of revenue carries its own risk, since the institution's own decisions can destabilize the provider.
Exit Planning
Plan the exit before signing, because the scenarios in which it matters are the ones where cooperation is unlikely: the vendor fails, is acquired, is terminated for cause, or exits the business.
Questions that need answers: can the institution get its data out, in a usable format, without the vendor's goodwill? How long would conversion take, and is that survivable? Who are the alternatives, and are they viable? What happens to in-flight transactions? Is there a documented plan someone could execute under pressure?
Structured coverage is available through the Certified Regulatory Vendor Program Manager program and its risk mitigation and business continuity levels, plus Assessing the Effectiveness of Your Vendor's BCP.
Governance and Where Programs Fail
The inventory is the foundation, and it is usually incomplete. Vendors engaged directly by departments, renewed automatically, or inherited in an acquisition are the ones missing. A reconciliation of the vendor inventory against accounts payable disbursements finds them, and every institution doing it for the first time finds some.
Ownership must be split correctly. The business owns the relationship and its risk; a vendor management function coordinates the lifecycle and maintains the inventory; risk and compliance set standards and challenge. Programs run entirely from procurement optimize for price and miss control failures. Programs with no business owner produce paperwork nobody uses.
Board reporting should cover the critical vendor population, the status of reviews, concentration, and any vendor whose condition or performance has deteriorated — not a count of completed questionnaires.
The recurring failures, stated plainly: an incomplete inventory; tiering by spend; assurance reports collected but not read; contracts without notification timelines or termination assistance; monitoring that stopped after year one; and no exit plan for any critical relationship.
The Core Processor Problem
Every community bank has one relationship that dominates its third-party risk, and the standard program handles it badly: the core processor.
The characteristics that make it different from every other vendor are worth naming. It is the largest single concentration of the institution's data and operations. Substitution is a multi-year project with substantial cost and real execution risk, so termination is a theoretical remedy rather than a practical one. Contract leverage is asymmetric — the institution is one of hundreds of clients on a standard agreement. And the relationship typically runs for five to seven years, during which the institution's needs change and the contract does not.
Four things a bank can actually do about it.
Negotiate at renewal, which is the only moment leverage exists. The items worth pushing hardest on are not price: they are audit and regulator access, incident notification timeframes, data portability in a usable format, service level remedies with teeth, and termination assistance obligations that survive the term.
Read the complementary user entity controls in the processor's assurance report. These are the controls the processor assumes the bank performs, and they are frequently substantial — access administration, reconciliation, review of specific reports. Institutions that have never read this list are relying on controls nobody is performing.
Test the exit assumption rather than asserting it. Ask concretely how data would be extracted, in what format, over what period, and at what cost. An institution that cannot answer has an exit plan in name only.
Track the interfaces. Core processors sit at the centre of a web of connected systems — monitoring, imaging, digital banking, reporting. A processor-side change can silently break a downstream control, which connects this directly to the change-risk discipline covered in the operational risk post.
The honest framing for a board: this is a concentration the institution cannot eliminate and should therefore manage deliberately, with the renewal treated as the principal risk event rather than a procurement exercise.
Frequently Asked Questions
Does using a vendor reduce the bank's responsibility?
No. Supervisory guidance is explicit that using a third party does not diminish the institution's responsibility to perform the activity in a safe and sound manner and in compliance with applicable law. Examiners review the bank's oversight of the vendor, and in some cases examine significant service providers directly.
How should vendors be tiered?
By the consequence of failure rather than by spend. Higher tiers are driven by support of a critical activity, handling of customer information, involvement in compliance obligations, access to bank systems, customer-facing conduct, difficulty of substitution, and money movement. Tiering by dollar value is the most common structural error in these programs.
What should a bank look for in a SOC 2 report?
Whether the scope covers the service, location, and period the institution actually uses; the exceptions listed in the testing results and whether they affect the institution; the complementary user entity controls, which assign work to the bank and are almost never read; and how recent the period is, with a bridge letter covering any gap.
What contract terms are most often omitted and regretted?
Termination assistance, covering orderly transfer of data and services on exit, and incident notification with specific timeframes rather than "promptly." Audit and regulator access rights, subcontractor disclosure with flow-down obligations, and data return and destruction terms are close behind.
What is fourth-party risk?
Risk arising from the vendor's own suppliers — the cloud provider behind the software, the offshore developer, the data center. The institution cannot contract with them directly, so the controls are contractual disclosure and flow-down plus assurance the vendor manages its chain. Concentration frequently hides here, with several apparently unrelated vendors depending on the same underlying provider.
How do you find vendors missing from the inventory?
Reconcile the vendor inventory against accounts payable disbursements. The missing ones are typically engaged directly by a department, renewed automatically, or inherited in an acquisition — and every institution performing this reconciliation for the first time finds some.
