Bank Vendor Risk Is Moving From Checklists to Control

Bank third-party risk management is entering a more consequential phase. On 13 November, the Federal Reserve, Federal Deposit Insurance Corporation, Office of the Comptroller of the Currency and National Credit Union Administration extended the comment period for their proposed interagency guidance from 16 November to 16 December. The extra month is procedural. The underlying question is not. Regulators are asking whether banks can replace broad vendor checklists with a genuinely risk-based system without turning “tailoring” into an excuse for weak control.

That distinction matters because modern banks are not self-contained institutions. Core processors maintain account records. Cloud providers host workloads. Fintech partners open distribution channels. Compliance vendors screen transactions. Data companies support underwriting, fraud detection and customer service. A small bank may depend on an external platform for capabilities that a larger institution can partly build in-house. Outsourcing can therefore improve competition, reduce fixed costs and accelerate innovation. It can also concentrate essential functions inside providers that individual banks cannot easily replace or fully inspect.

The agencies’ proposal tries to correct a real weakness in the 2023 framework. Supervisory experience suggests that banks often interpreted detailed examples as a universal checklist, devoting similar process to relationships with radically different risk. The new approach would emphasize risk identification, proportionate oversight, explicit residual-risk acceptance and governance. That is a sensible direction. A janitorial contractor should not receive the same scrutiny as a core processor connected to customer data and payment flows.

But proportionality changes the burden of proof. A checklist can be audited by counting completed steps. A principles-based system must show why one relationship deserves less work, why another deserves more, which risks remain after mitigation and who has authority to accept them. The quality of the judgment becomes the control. For investors, directors and depositors, the important test is whether banks become more selective and more resilient—or merely produce fewer documents.

The deadline extension is a signal, not the story

The joint 13 November announcement says the four agencies extended the consultation to 16 December. The proposal is principles-based and non-binding, and the agencies plan to replace existing third-party guidance if they finalize it. The Federal Reserve also extended the consultation on a separate companion guide for traditional community banks.

The extension creates more time for banks, credit unions, service providers and technology companies to address the practical questions hidden inside a simple phrase such as “risk-based oversight.” Which characteristics make a relationship high risk? How should a small bank assess a dominant provider that will not offer customized audit rights? When is alternative information enough? What evidence should support residual-risk acceptance? How should a bank account for subcontractors, shared cloud dependencies or a vendor that supports several business lines at once?

Those questions are difficult because third-party risk is not a single category. A provider can create operational risk by failing, compliance risk by mishandling customers, cyber risk through system access, financial risk through insolvency, strategic risk by locking the bank into an obsolete product and concentration risk when the same provider supports too much of the institution or too many institutions. One contract can contain several of these exposures at once.

The consultation should therefore be read as an attempt to improve allocation. The agencies are not saying that vendor risk matters less. They are saying that risk-management resources should follow the likely magnitude of harm. The practical consequence is that banks need a better map of dependency, not a shorter questionnaire.

Why the 2023 approach became process-heavy

The Federal Register proposal is unusually direct about the problem. It says the 2023 guidance was frequently interpreted too broadly and with insufficient tailoring. Banks struggled to determine which considerations applied to core providers, fintechs, maintenance vendors and other relationships. Detailed examples sometimes behaved like an implied checklist even though the guidance disclaimed prescriptive intent.

This produced a predictable response. If examiners might ask about every item, risk teams had an incentive to collect every item. If “critical activity” became a broad label, institutions had an incentive to apply heightened review widely. More files, questionnaires and approvals could then appear safer than prioritization. Yet the same process could divert scarce specialists away from the vendors that actually controlled payments, identity, customer data, account ledgers or business continuity.

The agencies also acknowledge a competitive effect. An impossible goal of eliminating vendor risk can discourage relationships with newer providers even when an incumbent is expensive, inflexible or underperforming. A young fintech may lack a long operating history but possess superior technology and experienced management. A dominant incumbent may have decades of history but poor contract terms, concentrated service architecture and limited responsiveness. Age is evidence, not a complete risk rating.

This matters especially for community and midsize banks. They need external technology to compete with national institutions, but they often have less negotiating power and fewer specialists. A framework that demands the same artifacts from every provider can reward scale rather than safety. It may also reinforce provider concentration by making the largest established vendor the easiest choice to defend.

The proposed correction is to focus on material financial risk, legal compliance and the bank’s particular circumstances. That can improve both safety and competition if it produces sharper prioritization. It can fail if “principles-based” becomes a euphemism for reducing evidence without improving judgment.

Four components replace the illusion of one checklist

The proposal organizes bank third-party risk management around four components: identifying and assessing risk, overseeing risk in proportion to its significance, making informed decisions about residual risk and establishing governance. These components are connected. Weak identification makes proportional oversight arbitrary. Weak oversight makes residual-risk acceptance uninformed. Weak governance makes the entire process difficult to challenge.

The first component begins with knowing which relationships exist. A large bank may need a detailed inventory that maps provider components to business units, reporting lines and accountability. A community bank may use a simpler structure. The point is not the format. The point is whether management can see which customer journeys, datasets, payment processes and recovery plans depend on each provider.

An inventory that lists legal entities but not services is incomplete. A single provider may host the core ledger, digital banking interface, fraud engine and customer-notification service. Four contract entries could describe one operational dependency. Conversely, one enterprise agreement may cover several independent services with different failure modes. Risk mapping must therefore follow function and impact, not only vendor name.

The second component is oversight. Due diligence, contract negotiation, monitoring and termination should be more rigorous when the potential harm is larger. A provider with access to sensitive data, authority over transactions or responsibility for essential infrastructure deserves different evidence from a low-risk professional service. The bank should understand financial condition, staffing, technical capability, controls, compliance history, cybersecurity, insurance and resilience to the extent relevant to the service.

The third component is residual-risk acceptance. This is the most important conceptual change. The agencies explicitly state that banks are not expected to eliminate third-party risk. Some risk cannot be removed, and some mitigation costs more than the benefit it provides. A bank may also lack bargaining power or realistic alternatives. The honest control is then to identify what remains, compare it with risk appetite and decide whether the relationship is still necessary and acceptable.

The fourth component is governance. Roles, risk appetite, board reporting, documentation and independent review convert individual judgments into an institutional system. Tailoring cannot depend on whoever owns the vendor relationship. It needs a repeatable path for challenge and escalation.

Concentration is the risk that simple tailoring can miss

A relationship can look manageable in isolation and still be dangerous in aggregate. The proposal recognizes that concentration may arise when one provider supplies extensive services. The deeper issue is that concentration has several layers.

The first is bank-level concentration. One institution may depend on a single core processor for most account activity. If that provider fails, the bank may retain legal responsibility but lack the operational capacity to serve customers.

The second is sector concentration. Many banks may use the same core, cloud, identity or compliance provider. Each institution may have acceptable controls, yet a common outage can affect a large part of the system. Individual due diligence cannot fully solve a shared dependency.

The third is fourth-party concentration. Two vendors that appear independent may rely on the same cloud platform, data supplier or authentication service. Buying a second vendor does not create resilience if both fail through the same underlying component.

The fourth is knowledge concentration. A bank may technically own its data and contracts while losing the internal expertise required to understand the system. If only the vendor can explain the architecture, test recovery or reconstruct decisions, the bank has outsourced judgment as well as execution.

Block2Learn previously examined how bank AI concentration risk can become systemic. The same logic applies beyond artificial intelligence. A platform can improve capability and reduce unit costs while becoming a control point for data, models, identity and workflow. Efficiency and fragility can rise together.

This is why the shift from checklists to tailoring must not reduce attention to architecture. A bank can justifiably perform less review on a low-impact vendor. It cannot justify treating a highly integrated provider as lower risk simply because the contract is familiar or the company is regulated.

A regulated vendor is not a transferred responsibility

The proposal preserves a core rule: using a third party does not reduce the bank’s responsibility to operate safely and comply with law. That remains true when the provider is an affiliate, a regulated company or a subcontractor, and even when risk-management work itself is outsourced.

This boundary is essential because regulatory status can create false comfort. A regulated provider may be supervised for a different activity, under a different legal standard or by an authority focused on different risks. It may also be financially weak, operationally fragile or badly matched to the bank’s use case. The existence of supervision is useful information; it is not a substitute for the bank’s own assessment.

The same distinction appeared in Block2Learn’s analysis of the Coinbase and Stablecore bank-software partnership. A specialist can supply custody, trading or payment orchestration, but the bank cannot outsource the legal consequences of the product. The contract allocates tasks. It does not erase accountability.

For investors, this means vendor strategy belongs inside bank analysis. Technology spending is not only an efficiency line. It affects operational resilience, compliance exposure, product speed, customer retention and the probability of costly remediation. A bank with a disciplined external architecture may innovate faster with less fixed cost. A bank that cannot challenge its providers may appear efficient until a disruption reveals the hidden dependency.

Due diligence should test capability, not reward paperwork

The proposed guidance gives banks more room to use alternative information when a provider does not supply every requested artifact. That is practical. A startup may lack a decade of audited performance. A large technology company may refuse a bespoke on-site review. A community bank may have little leverage to change standard terms.

The correct response is not automatic rejection or automatic acceptance. It is to ask whether other evidence answers the material questions. Management experience, independent assessments, technical certifications, financial support, incident history, reference customers and tested controls may compensate for missing information. The evidence should match the risk.

For a critical payment or core-processing relationship, due diligence should demonstrate more than general competence. The bank needs to know how the service fails, how data are preserved, how access is revoked, how incidents are reported, how capacity behaves under stress and how service can be restored. It should understand where subcontractors sit in the chain and whether the provider can change them without meaningful notice.

For a lower-risk relationship, the bank may reasonably rely on public records, standard certifications or a narrower review. The expected harm is smaller, so the cost of exhaustive due diligence may not be justified. Tailoring is credible when management can explain this difference before an incident, not only after one.

The FDIC’s community-bank guide already described the life cycle: planning, due diligence, contract negotiation, monitoring and termination. The new proposal does not eliminate that logic. It reduces the temptation to treat every possible consideration as mandatory for every relationship.

Contracts matter most when the relationship stops working

Vendor contracts often receive attention at onboarding and neglect thereafter. Yet their most important provisions govern stress: audit rights, incident notification, data access, subcontracting, service levels, indemnification, termination and transition support.

A bank can accept standard commercial terms for a low-risk service. It should be more cautious when a vendor controls customer records, transaction processing or access to essential systems. A weak right to obtain information can make ongoing monitoring performative. A narrow liability cap can leave the bank absorbing losses created by provider failure. An ambiguous data-export clause can turn exit into a negotiation at the worst possible moment.

The agencies’ proposal recognizes that insurance, guarantees and indemnification may mitigate risk, but only if the relevant party can meet the obligation and the coverage matches the exposure. A contractual promise is not liquidity. Recovery may require litigation, and coverage may exclude the incident that actually occurred.

Termination is equally important. The bank needs to understand remaining contract cost, data migration, customer communication, regulatory notice, operational testing and the availability of replacement providers. A theoretical alternative is not a recovery plan if conversion requires eighteen months, proprietary formats cannot be exported or staff no longer understand the underlying process.

This is where bargaining power becomes a measurable risk. If a provider will not permit meaningful audit, will not disclose important subcontractors and will not support portable data, the bank may still decide the relationship is necessary. That decision should appear as explicit residual-risk acceptance, not disappear inside a procurement approval.

Cloud risk shows why shared responsibility must stay visible

The FFIEC’s statement on cloud computing explains that responsibility is divided according to the service model, while the institution retains overall responsibility for safety, soundness and protection of sensitive customer information. This is a useful model for all material third-party relationships.

Cloud infrastructure can be more resilient than a small bank’s own data center. It can provide geographic redundancy, security expertise and scalable capacity. But it also changes the control boundary. The provider may secure physical infrastructure while the bank remains responsible for identity, configuration, data classification, applications and recovery design. An outage caused by a bank’s configuration error is still an outage. A secure provider cannot compensate for weak access governance at the customer.

Shared responsibility fails when each side assumes the other owns a control. It also fails when the bank buys several vendor products but does not understand their interaction. Identity, logging, encryption, backup and incident response must work across the stack, not merely inside individual contracts.

The proposed guidance can improve this if banks use tailoring to concentrate on interfaces and failure paths. It can weaken control if institutions reduce oversight because a provider has a familiar certification. Certifications can support due diligence. They cannot prove that the bank’s particular configuration, data flow and recovery process are sound.

Residual-risk acceptance is not permission to ignore weakness

The agencies’ acceptance that some vendor risk is unavoidable is realistic and important. Banks cannot operate without external providers, and no control reduces risk to zero. The danger is that “risk acceptance” becomes an administrative closing device rather than a management decision.

Credible acceptance should identify the risk, the missing mitigation, the expected impact, the reason further reduction is impracticable, the compensating controls, the accountable decision-maker and the conditions that would trigger reassessment. It should also have an expiry or review point. A risk accepted because there was no alternative in 2026 may become unacceptable when technology, pricing or provider performance changes.

The decision should be made at the level that owns the economic consequence. A product manager may understand the commercial need, but a material operational exposure may require senior management or board visibility. Independent challenge matters most when the business is under pressure to launch quickly.

The same discipline applies to affiliates. Intra-group services can be efficient, but familiarity does not remove concentration, data or recovery risk. Block2Learn’s review of Coinbase Ireland’s safeguarding controls showed how centralized group systems can concentrate the roles of designing, operating and testing a control. The problem was not outsourcing itself. It was whether the regulated entity retained enough independent substance to understand and challenge the arrangement.

Community banks need cooperation without surrendering judgment

Small institutions face a structural disadvantage. They may buy the same critical services as larger banks but lack comparable negotiation leverage, engineering staff or specialist risk teams. The agencies therefore allow room for collaborative due diligence, credible summaries, shared assessments and external expertise.

This can reduce duplication. Ten community banks do not necessarily need ten separate teams to test the same technical control. Shared work can improve quality and give smaller customers more leverage. It can also help institutions compare incidents, contract terms and service performance.

But collaboration should supply evidence, not replace judgment. Each bank uses the service differently, integrates it with different systems and serves a different customer base. A shared assessment cannot determine whether a particular bank’s data architecture, risk appetite or recovery plan is adequate.

The agencies’ joint statement on community banks and core service providers is important here. Supervisors can consider the realities of provider leverage, but the bank still needs to show that it understands the relationship and responds to material risk. Tailoring should make this expectation more achievable, not less real.

Innovation becomes safer when the exit is credible

The proposal is partly designed to remove barriers to prudent innovation. That objective is economically sound. Community banks should not be forced into outdated systems merely because incumbent providers produce familiar compliance packages. Fintech partnerships can expand access, improve customer experience and lower development cost.

Yet innovation is strongest when it is reversible. A bank that can export data, separate customer access, monitor service quality and transition providers has more freedom to experiment. A bank locked into proprietary workflows has less strategic flexibility even if the product initially looks innovative.

This is why exit planning is not a pessimistic exercise. It is a competitive capability. Portability increases bargaining power. Clear service ownership improves product design. Tested fallback procedures reduce the cost of changing direction. A bank that knows how to leave a vendor can often negotiate a better relationship with that vendor.

The investor implication is counterintuitive. The fastest launch is not always the most innovative strategy. A slower implementation with clear data rights, modular architecture and tested recovery may create more durable optionality. Conversely, a rapid partnership that concentrates core functions can increase future switching costs and operating leverage against the bank.

Three outcomes for the new framework

The first and best outcome is genuine risk differentiation. Banks simplify low-risk reviews, redirect specialists toward critical providers, map concentration and make residual-risk decisions explicit. Community banks gain access to newer technology without pretending that every vendor is equivalent. Documentation becomes shorter where risk is lower and deeper where failure would matter.

The second outcome is compliance compression. Institutions reduce questionnaires and approvals but do not improve inventories, architecture maps or challenge. “Tailoring” becomes a label placed on old commercial decisions. This lowers visible process cost while leaving dependency unchanged. The next incident then produces a familiar question: why did management not understand how much of the bank depended on one provider?

The third outcome is defensive re-concentration. Banks interpret uncertainty as a reason to favor the largest vendors, because their certifications and documentation are easiest to present. Smaller providers struggle to enter, while incumbent platforms gain more pricing power and systemic importance. The framework would then reduce process burden but weaken competition.

Which outcome prevails will depend less on the final wording than on implementation. Examiners must respect reasonable judgments, as the proposal promises, while challenging unsupported conclusions. Boards must ask about concentration and exit, not only completion rates. Vendors must provide evidence that customers can actually use. Banks must preserve internal knowledge even when execution is external.

What investors should monitor

The first signal is whether banks disclose more about material technology dependencies and operational incidents. Vendor names may remain confidential, but management should be able to describe concentration, resilience investment and the effect of major outages.

The second is technology expense. Lower process cost can improve efficiency, but sudden savings may indicate deferred control work. Investors should distinguish automation of repetitive due diligence from cuts to engineering, resilience testing or independent review.

The third is contract and conversion activity. A bank changing core providers accepts near-term execution risk in exchange for longer-term capability. Delays, cost overruns and customer disruption can reveal weak planning. A successful conversion can increase product speed and reduce legacy cost.

The fourth is regulatory criticism. Because the guidance is non-binding, supervisory action should relate to law, unsafe practices or material risk rather than failure to follow an example. That makes the substance of findings more important. Repeated weaknesses in data access, complaint handling, transaction monitoring or recovery can indicate that the third-party system is not under control.

The fifth is product economics. Fintech distribution may expand deposits, payments or lending, but the bank must retain enough margin to fund oversight and absorb risk. A partnership that produces rapid volume with thin economics can become unattractive once compliance, fraud and service costs are fully recognized.

Block2Learn’s analysis of the SEC’s 2027 examination priorities made a related point for investment firms: cloud and outsourced services can expose customer information even when internal controls appear strong. Across financial regulation, the direction is similar. The institution cannot treat external technology as outside its control environment.

The Block2Learn assessment

The agencies are right to move away from one-size-fits-all vendor checklists. A process that demands similar evidence from every relationship wastes resources, discourages useful competition and can distract from the providers that actually matter. Risk-based tailoring is not deregulation in the simple sense. Done properly, it is a demand for better judgment.

The proposal is strongest where it recognizes residual risk and bargaining constraints. Community banks cannot force dominant providers to accept every contract term or disclose every detail. Pretending otherwise turns guidance into fiction. Management should be allowed to use alternative evidence and accept some risk when the service is necessary and the remaining exposure fits the bank’s risk appetite.

The proposal is weakest if readers interpret proportionality only at the contract level. Modern concentration sits across services, vendors and fourth parties. A provider that appears manageable in one business line may be critical across the institution. Two separate vendors may share one cloud dependency. A bank may retain legal responsibility while losing the knowledge needed to exercise it.

The final guidance should therefore preserve a clear expectation that banks understand service architecture, concentration and exit feasibility for their highest-risk relationships. It should encourage shared assessments and certifications without allowing them to substitute for institution-specific judgment. It should also make governance of residual-risk acceptance visible enough that boards can challenge it.

For investors, vendor management is becoming part of the bank’s strategic moat. The strongest institutions will not be those that outsource the least. They will be those that combine external capability with internal control, use partnerships without losing technical understanding and preserve the option to change providers when economics or risk deteriorate.

Control, not paperwork, is the final test

The extended consultation gives the banking industry another month to shape the framework. The more important deadline will come later, when banks must show that a principles-based system can make difficult distinctions consistently.

Low-risk vendors should receive proportionate attention. Critical providers should receive deep scrutiny. Concentration should be mapped across the stack. Residual risk should be accepted consciously, by accountable people, with compensating controls and a reason to revisit the decision. Exit plans should be credible enough to strengthen bargaining power before failure occurs.

If the new framework produces that discipline, it can support both resilience and innovation. Banks will spend less time proving that every box was checked and more time understanding where customer service, data and money can actually stop.

If it does not, the industry may reduce paperwork while preserving the same dependencies. The next outage or control failure would then reveal that the checklist was never the problem. The problem was whether the bank knew which external system had become essential—and whether it could still control the outcome.

Continue Through the Block2Learn Learning Path

Bank third-party risk management sits at the intersection of operational risk, regulation, technology architecture, competition and governance. Understanding it requires more than memorizing a vendor life cycle. Readers need a framework for judging how incentives, concentration, contractual rights and residual risk interact.

The Block2Learn Learning Path develops that structure progressively. Free Start introduces the language of markets and risk. Foundation builds the principles of capital allocation and financial decision-making. The Investor Operating System turns those principles into a repeatable process for evaluating incomplete evidence, competing objectives and uncertain outcomes.

That progression matters because third-party risk is not solved by choosing between “outsource” and “build.” The real work is deciding which capabilities can sit outside the institution, which knowledge must remain inside, what evidence supports the arrangement and when a concentration has become too important to accept without stronger control.

Information is abundant. Structure is rare.