Vendor Sprawl: Running a Third-Party Review That Survives an Exam

A community bank counts its technology vendors and arrives at 43. Nobody chose 43. Each one was individually justified: a point solution for eSignature, another for identity verification, another for remote online notarisation, one for fraud, two for reporting, and a handful inherited from a merger.

The instinct is to consolidate. That instinct is right and incomplete, because sprawl is a symptom rather than the disease. Consolidating without fixing what caused it produces the same sprawl in three years with different logos on it.

What actually causes sprawl

No one owns the architecture. When a business unit has a problem and budget, they solve it. That is not dysfunction, it is initiative. Sprawl happens when nobody is responsible for asking whether the capability already exists somewhere in the stack.

Point solutions arrive faster than platform ones. A department with a real problem this quarter will not wait for a roadmap item next year, and they are correct not to.

Nothing gets removed. Adding a vendor has a champion. Removing one has none, and carries the risk of breaking something nobody documented. So the count only rises.

Mergers multiply. Two institutions combine and the stack is the union of both, minus whatever was too obviously redundant to survive the first review.

Fix the ownership gap or the review is a one-time cleanup rather than a change in trajectory.

Build the inventory properly

Most institutions have a vendor list. Almost none have an inventory, and the difference matters.

A list has names and contract values. An inventory has, for each vendor:

What data they touch, specifically. Member PII, account numbers, transaction detail, credentials. Not "member data" as a category.
How they connect. API, SFTP file drop, direct database access, or a service account somebody created and forgot.
What breaks if they stop. The honest answer, tested if possible, not the answer from the sales deck.
Contract dates, with the notice window for non-renewal.
The internal owner. A person. Departments do not renew contracts; people do.
Whether they subcontract, and to whom. Fourth-party risk is where the surprises live.
Whether they run models on your behalf. See the AI governance piece; this is increasingly examined.

The service accounts are the item people skip and the item examiners find. Every institution has integrations running under credentials belonging to someone who left in 2021.

Build this before deciding anything. A consolidation decision made without it is a guess.

Concentration risk cuts both ways

The vendor management conversation usually treats concentration as the thing to avoid. Examiners look at it from both directions, and so should you.

Too concentrated means one vendor holds so much of your stack that you have no leverage in negotiation, no alternative if service degrades, and a single failure domain covering multiple critical functions. Core providers who have expanded into digital banking, payments, and analytics create exactly this.

Too fragmented means dozens of vendors each requiring due diligence, contract management, security review, and an owner. Inventory and oversight overhead scales with the count rather than the spend, while the depth of diligence should scale with what each vendor can reach. Those two do not line up, which is how small vendors end up receiving proportionally less scrutiny while touching equally sensitive data.

Neither extreme is safe. The defensible position is deliberate: you can articulate why each critical capability sits where it does, and what the alternative is if it fails.

That articulation is what an examiner is actually testing, whichever regulator sends them. For banks, the Interagency Guidance on Third-Party Relationships issued by the OCC, FDIC and Federal Reserve in June 2023 replaced each agency's separate guidance and sets the expectation across the whole relationship lifecycle. For credit unions, NCUA's 2026 supervisory priorities name third-party risk management, including functions outsourced to third parties. The question is rarely "why do you use this vendor". It is "what happens if they fail, and can you demonstrate you have thought about it".

Deciding what to consolidate

With the inventory in hand, sort by two axes: how critical the capability is, and how much overlap exists with something else you already pay for.

Consolidate when several vendors deliver overlapping capability, when a platform you already own covers a point solution adequately, or when the compliance overhead of a small vendor exceeds the value they deliver. That last case is common and under-recognized: a vendor costing $12,000 a year and consuming a week of security review, contract management, and annual diligence is not cheap.

Do not consolidate when the point solution is meaningfully better at something that matters to members, when consolidating increases concentration on a vendor you already depend on heavily, or when the migration cost exceeds several years of the savings. Vendor rationalisation projects have a habit of costing more than they save while producing a slide showing the count went down.

Be honest about switching costs. The stated cost of moving is the implementation fee. The real cost includes staff retraining, the integrations you rebuild, the reports that need recreating, and the six months where both systems run.

Make it a standing program, not an annual scramble

The pattern to avoid is a burst of review activity before an examination, followed by 11 months of nothing.

What works instead is modest and continuous:

Contract calendar with owners, reviewed monthly. The renewal you miss is the leverage you lose.
Tiered diligence. Critical vendors get annual review with documented evidence. Low-risk vendors get a lighter touch. Applying the same depth to everything means either drowning or doing it badly.
New vendor intake with an architecture question. Before purchase: does this capability already exist in the stack? The question only works if somebody can make the answer stick, because the business unit will argue the incumbent is clunky and missing the one feature they need, and sometimes they are right. What it buys is a decision on the record rather than a purchase nobody reviewed.
An exit plan for every critical vendor, written while the relationship is healthy. Nobody negotiates a good exit during a bad one.

None of this is sophisticated. It is the sort of unglamorous operational discipline that produces a clean examination and, more usefully, an institution that can actually change vendors when it needs to.

The measure of a good third-party program is not the size of the binder. It is whether you could leave your most important vendor within a defined timeline, and know what that would cost.

We provide senior engineering ownership of vendor and architecture decisions, independent of any provider. See technology leadership for community banks and for credit unions, or book a call.