Third-party risk isn’t just about vendor contracts anymore. US, UK, and EU regulators are now examining the entire operational backbone—data flows, incident response, concentration risk, and how banks handle vendor failures when markets move fast.
What Changed and Why Regulators Care Now
For years, third-party risk management at most banks looked like a spreadsheet and an annual questionnaire. Vendors got scored. Contracts were signed. Risk committees moved on. That fiction ended around 2022–2023.
The Federal Reserve, the Office of the Comptroller of the Currency (OCC), and the Financial Conduct Authority (FCA) all began publishing concrete guidance—not principles, not “best practice suggestions,” but specific examination expectations. The European Central Bank (ECB) followed. These weren’t rhetorical updates. They reflected real exam findings: banks didn’t know what their critical vendors actually did. They couldn’t measure vendor performance in real time. They had no playbook for when a vendor went down.
Buried in the guidance is something practitioners often miss: regulators are no longer focused primarily on contractual language. They’re focused on operational visibility—can your bank actually see, measure, and respond to third-party failures?
The US Framework: Federal Reserve SR 17-4 and Beyond
The Federal Reserve’s Supervisory Guidance on Third-Party Relationships (SR 17-4, updated 2020) set the tone: banks must assess, monitor, and manage third-party risk across the entire financial services chain. That’s vendor selection, due diligence, ongoing monitoring, and incident response.
What actually matters to Fed examiners today is this: Can you produce a list of “critical” third parties? If your bank’s settlement vendor fails for six hours, can you quantify the impact? Do you have real-time visibility into whether that vendor’s service level agreement (SLA) is being met?
Regional banks under $50 billion in assets have struggled hardest here. Larger institutions often have dedicated third-party risk teams. Smaller firms outsource critical functions—loan origination, payment processing, securities clearing—to vendors and then lack the infrastructure to monitor them properly.
The OCC’s 2020 guidance expanded this. It specifically called out concentration risk: if one vendor processes more than a defined threshold of your critical operations, that’s now a direct examination topic. OCC examiners ask: “What’s your contingency if this vendor’s systems go offline? How do you stand up parallel processing? Can you execute it in 24 hours?”
Most banks can’t answer that question precisely. That silence is what examiners record in their findings.
The UK Approach: FCA Rules and Operational Resilience
The FCA took a different path—more principle-driven, but with sharp teeth. The UK’s operational resilience rules (which took full effect in 2025) require firms to identify “important business services”—the operations that, if disrupted, would cause severe detriment to the firm or the market.
For third-party risk, this changes everything. Your vendor is no longer just “a risk to manage.” It’s part of your critical path. If your data analytics vendor is supplying input to your anti-money laundering (AML) transaction monitoring system, and that vendor goes offline, your AML control is offline too. The FCA treats this as an operational resilience failure, not just a vendor problem.
FCA examiners now ask: Do you have real-time alerting when a critical vendor’s performance degrades? Can you measure the latency in your vendor’s API responses? Do you have a documented threshold below which you trigger an escalation? If your vendor’s uptime drops below 99.8%, what happens?
The guidance specifically requires firms to test third-party continuity plans at least annually. Not paperwork. Not a theoretical scenario. Live testing. This has forced UK banks to build actual failover infrastructure and to hire or contract operational teams capable of standing up replacement services on short notice.
The EU Standard: ECB, EBA, and DORA
The European framework is layered. The ECB’s “Recommendation on information and communication technology (ICT) security and governance” (2017, clarified 2022) requires banks to classify third parties by criticality and to conduct on-site assessments of critical ICT service providers.
That “on-site assessment” language is important. It doesn’t mean a questionnaire. It means someone from your bank, or your approved third-party auditor, visits the vendor’s facility, reviews their incident logs, tests their backup systems, and verifies their security controls directly.
The EU’s Digital Operational Resilience Act (DORA), which applies from 2025 onward, layers in additional requirements. DORA creates a formal regime for “critical ICT third-party service providers”—essentially, vendors so important to European financial stability that regulators can impose direct requirements on them. For banks, this means mapping which of your vendors fall into that category and preparing for direct regulatory oversight of those relationships.
The EBA’s guidance clarifies that banks must conduct impact assessments for each critical third party: If this vendor fails, what’s the maximum acceptable duration of disruption? How long can you operate in degraded mode? What’s your recovery time objective (RTO) and recovery point objective (RPO)?
Many EU banks are discovering they haven’t formally documented these metrics. Examiners are now asking to see them. The absence of a documented RTO is itself a finding.
What Regulators Are Actually Examining in Real Time
Third-party risk examinations across all three jurisdictions now focus on five concrete areas:
1. Vendor Criticality Classification
Examiners ask: How did you decide which vendors are critical? Is the process documented? Is there a committee that reviews this periodically? Most banks fail here because the classification is ad hoc—”Well, if they go down, we’re in trouble” is not a satisfactory answer. Regulators want a formal matrix: impact severity (critical/high/medium), probability of disruption, concentration metrics, and then a clear decision rule.
2. Real-Time Monitoring and Performance Metrics
Can you show me your vendor dashboard? This is asked constantly. Examiners expect banks to have automated feeds that report key metrics—API uptime, latency, error rates, transaction volumes. If you’re still relying on vendor-provided monthly reports, examiners will document this as a control weakness.
3. Concentration Risk Across the Ecosystem
Examiners produce concentration reports: How many critical vendors provide similar services? If your cloud infrastructure is 100% AWS and your backup cloud is 100% Azure (owned by Microsoft), you have concentration risk if both providers experience simultaneous issues tied to shared dependencies—like widespread power grid disruptions. Regulators now ask banks to model this.
4. Incident Response and Communication Protocols
When a vendor experiences a security incident, data breach, or operational failure, how does your bank know? Is there a formal notification protocol in your contract? Do you have an escalation path? Most critically: can you execute a coordinated response—communications to customers, regulators, internal stakeholders—within a defined time window?
One US regional bank’s exam in 2024 found that a payment processor experienced a security breach, but the bank didn’t discover it for three weeks because the vendor had no formal notification obligation.
5. Backup and Continuity Testing
Examiners want evidence of testing. Not just walk-throughs. Real tests. The Fed and FCA both expect banks to document annual tests of critical vendor failover. If your bank has never actually stood up a backup payment processor, that’s a finding. If you’ve tested it but the test took 16 hours to complete—longer than your documented RTO—that’s also a finding.
Why Concentration Risk Is the Silent Killer
The 2023–2024 banking stress (US regional bank failures, UK gilt market volatility) revealed something: banks often don’t understand their vendor concentration. Three banks all use the same cloud provider. That provider experiences a regional outage. All three banks lose critical functions simultaneously. Regulators now stress-test for this.
The ECB’s stress test scenarios for 2024–2025 specifically included vendor concentration events. The Fed is building similar scenarios into capital and liquidity stress tests. This means banks now need to quantify: If my top three vendors all went offline simultaneously, how long before I lose revenue? How long before I breach regulatory capital minimums?
The Practical Implication: Build Operational Visibility or Face Findings
Banks that score well in third-party risk exams today have three things in common:
One: They’ve created a formal third-party risk committee with clear governance—typically chaired by the chief risk officer or head of operational risk, with IT, compliance, and business unit representation.
Two: They’ve invested in monitoring infrastructure—dashboards that pull real-time data from critical vendors, automated alerting when SLAs degrade, and documented response protocols.
Three: They’ve built or contracted alternative capacity for critical functions. This doesn’t mean you need a fully staffed backup operations center. It means you’ve identified which vendor functions are truly irreplaceable, you’ve negotiated rights to failover with a secondary provider, and you’ve tested that failover at least once annually.
Banks that score poorly typically have fourth and fifth weaknesses: They don’t understand concentration—they assume vendors are geographically diverse or technically independent when they’re not. And they lack incident response protocols—when a vendor fails, the bank scrambles rather than executing a predetermined plan.
How Third-Party Risk Intersects with Other Regulatory Priorities
Third-party risk is no longer siloed. It now intersects directly with DORA compliance (EU), operational resilience rules (UK), and capital adequacy (all jurisdictions). For example, if your bank outsources core credit risk calculations to a vendor, and that vendor’s AI model fails or degrades, you’re now exposed to both operational risk (vendor failure) and model risk (incorrect risk metrics driving capital calculations). Regulators increasingly expect banks to manage both.
Similarly, if you use a third-party for AML transaction monitoring, you’re delegating a regulatory responsibility. The regulator still holds your bank accountable if the vendor’s monitoring is inadequate—which is why the FCA and other regulators now require banks to validate vendor outputs independently, not just trust vendor assertions.
The Algoy Perspective
Most banks treat third-party risk management as a compliance checkbox. Regulators treat it as an operational integrity issue. The gap between these worldviews is where failures happen.
Here’s what’s being missed: the vendors themselves are consolidating. There are only a handful of global custodians, a small number of dominant payment processors, an even smaller number of cloud providers. This structural consolidation means concentration risk is rising even as individual banks think they’re diversifying. A bank with vendors spread across five different companies sounds diversified until you realize all five vendors use the same cloud infrastructure or all depend on the same communications network.
Regulators see this. Examiners now ask: “Show me your vendor’s vendor stack. What are their critical dependencies?” Most banks can’t answer. Your vendor’s vendor is now your indirect third-party risk, and regulators are starting to expect banks to manage it.
The strategic implication: firms that invest in third-party visibility and control today will have a competitive advantage tomorrow. They’ll pass exams faster. They’ll be able to move faster when markets disrupt (because they’ll have tested failover procedures). And they’ll be able to respond to regulatory requests in real time rather than scrambling to compile data.
Frequently Asked Questions
What counts as a “critical” third party under current guidance?
Any vendor whose failure would prevent you from executing a critical business function within your documented recovery time objective. This typically includes payment processors, custodians, settlement agents, core banking systems providers, and increasingly, AI/ML model vendors. The ECB guidance specifically requires on-site assessments of critical ICT providers; the Fed and FCA expect documented impact assessments for each critical vendor.
Do I need to conduct on-site audits of all my vendors?
No. The ECB requires on-site audits only for “critical ICT third-party service providers.” The Fed and FCA expect documented risk assessments for all critical vendors; on-site audits may be required for highest-risk vendors or those managing sensitive data. However, the trend globally is toward more on-site activity, not less. If you haven’t conducted any on-site vendor assessments, examiners will view that as a control gap.
What incident response protocols should be documented in vendor contracts?
Contracts should specify: (1) how the vendor notifies your bank of material incidents (definition of “material” included); (2) notification timeframe (typically within 2–24 hours); (3) required escalation path; (4) vendor’s obligation to cooperate with regulator notifications; (5) your right to audit the vendor’s incident response; (6) consequences if notification is delayed. Most current contracts are vague on these points. Regulators are flagging this as a finding.
How do I validate that a vendor’s cloud infrastructure meets my continuity requirements?
Request the vendor’s most recent SOC 2 Type II audit report (or equivalent third-party security assessment). Review their documented RTO and RPO. Conduct a live failover test annually. Document the results and any gaps. If the vendor resists providing this information, that’s a red flag—it may indicate they’re not equipped to serve a regulated financial institution.
