The Integration Requirement Your BCP Is Missing: What FFIEC Examiners Actually Check on Vendor Business Continuity

TL;DR

• The FFIEC’s 2019 Business Continuity Management booklet shifted from “do you have a vendor’s BCP?” to “have you integrated it into your own plan?”—a requirement most fintech BCP programs satisfy on paper but not in substance
• Examiners checking vendor BCP documentation want five things: the vendor’s current BCP, test results, modification notifications, your integration document, and your own testing evidence
• “End-to-end testing” means validating your recovery capability when the vendor is also down—not just filing their test summary
• Critical services require annual or more frequent testing of the integrated contingency plan, not just your internal procedures

Here’s the scenario: your examiner opens your business continuity binder. They flip past your risk assessment, your BIA, your recovery time objectives. They land on the vendor section. They ask: where’s your core processor integration?

Not the processor’s BCP. Your integration of the processor’s BCP into your plan.

There’s a difference. Most compliance teams have the former. The examiner wants the latter.

From Planning to Management: What the 2019 Booklet Actually Changed

The FFIEC’s Business Continuity Management booklet, released in November 2019, wasn’t a cosmetic update. The name change—from “Business Continuity Planning” to “Business Continuity Management”—signaled a deliberate shift in scope and expectations.

BCP had always been primarily about your institution’s ability to recover its own operations. The 2019 booklet reframed BCM as a management discipline that includes the full ecosystem your operations depend on: affiliates, third parties, critical vendors, and the technology infrastructure behind all of them.

Practically, that means the vendor section of your BCM program can no longer be a collection of vendor-supplied documents. The booklet now expects institutions to:

• Assess whether vendors have adequate BCM programs and recovery capabilities commensurate with the criticality of their services
• Integrate applicable portions of those programs into the institution’s own continuity plan
• Test the integrated procedures, including end-to-end exercises with critical service providers where appropriate
• Monitor ongoing: vendors must notify you of material BCP modifications

This isn’t new law. It’s been in the booklet for seven years. But it’s consistently one of the areas where fintech BCM programs show gaps in examination—particularly the integration and testing requirements.

As Protiviti’s analysis of the updated booklet noted, the booklet moved third-party considerations from an appendix into the main body of BCM requirements—signaling that vendor dependency isn’t a footnote to business continuity; it’s central to it.

What “Integration” Actually Means

Here’s where programs typically fall short. Integration doesn’t mean:

• Filing the vendor’s BCP summary in your BCM folder
• Including the vendor’s RTO/RPO in your risk assessment
• Noting “Vendor X has a documented BCP” in your TPRM due diligence

Integration means you’ve written down, in your own plan, what your institution does when that vendor goes down. Specifically:

Who gets notified and when. If your core processor declares a disaster at 6am on a Saturday, which person at your institution gets the call? Who at the vendor do you contact? What’s the escalation path if the primary contact is unreachable?

What manual procedures exist. If the vendor’s system is offline for four hours, eight hours, 24 hours—what do your operations teams actually do? Is there a manual fallback? Does anyone know where it is?

How the vendor’s recovery timeline affects your RTO. If your payment processor has a four-hour RTO for their primary data center and your institution has a two-hour RTO for customer-facing payment services, you have an incompatibility. That gap needs to be addressed in your plan—not just noted in a TPRM risk assessment.

What triggers plan invocation. Under what circumstances do you invoke your BCP for a vendor-caused disruption? Who makes that call? Is there an authority matrix?

The FFIEC’s outsourcing and business continuity guidance is explicit: if a financial institution uses a service provider to process daily transactions, management should ensure that the institution has incorporated applicable guidelines from the vendor’s BCP into the institution’s own plan, communicated the relevant functions to appropriate personnel, and maintained and periodically reviewed the combined plan.

The operative word is “combined plan”—not their plan filed in your folder.

The Five Documents Examiners Want in Your Vendor BCP File

Based on the BCM booklet requirements and how they translate into examination practice, here’s the documentation set for each critical vendor relationship:

Most fintech BCM programs have the first two. The modification notification log is frequently missing—institutions don’t have a mechanism for vendors to report changes, or a process for tracking when notifications were received and reviewed. The integration document and testing evidence gaps are where examination findings originate.

End-to-End Testing: The Requirement Most Programs Skip

The FFIEC BCM booklet calls for end-to-end testing with critical service providers “where appropriate.” In practice, that means your tabletop exercise or failover test should include the scenario where the vendor system is also unavailable—not just where your internal systems fail.

Here’s the gap this exposes: a fintech might test its own disaster recovery procedures thoroughly—failover to backup systems, communication trees, manual processing protocols. But if every one of those recovery procedures depends on a payment rail, a core processor, or a cloud provider being available, the test hasn’t actually validated recovery. It’s validated that internal systems work when vendors are up.

An end-to-end exercise for a critical vendor dependency asks: if Vendor X’s systems are offline for 36 hours, can we operate? Not just “do we have a BCP that says we’ll wait for them to recover.”

For a structured framework for running and evaluating these exercises, see the tabletop exercise evaluation rubric we published last week—it walks through how to score exercise outcomes, identify gaps, and document remediation in a way that satisfies BCM examination standards.

Why Post-Synapse Scrutiny Changed This Conversation

The Synapse Financial Technologies bankruptcy in April 2024 clarified what happens when business continuity planning doesn’t account for vendor failure in ways that directly affect customer funds. When Synapse filed Chapter 11, approximately 200,000 customer accounts were frozen as the bankruptcy trustee attempted to reconcile a ledger shortfall estimated at $65 million to $95 million.

For fintechs operating through BaaS middleware, Synapse wasn’t a technical outage. It was a legal and operational collapse that no BCM program had scenario-planned for: a middleware provider filing bankruptcy while the ledger obligations between fintechs, the middleware, and the underlying sponsor banks couldn’t be settled.

The supervisory response reinforced the BCM message. OCC consent orders against Community Federal Savings Bank (May 2026) and United Texas Bank (June 2026) showed that banks are accountable for the operational risks that fintech-partner volume introduces—including the continuity risks that vendors in the fintech stack create. For an analysis of what those consent orders mean for fintech programs when the bank partner is the one getting examined, see our OCC BaaS partner consent order breakdown.

In the post-Synapse environment, “we have the vendor’s BCP on file” is not a satisfactory answer to the question of whether your institution has BCM. Examiners—and your sponsor bank’s oversight team—now want to see evidence that you’ve stress-tested your operations against vendor failure, not just vendor delay.

Building Your Vendor BCP Integration File

For each critical or high-risk vendor, your BCM documentation should include:

Step 1: Criticality determination. Define which vendors are “critical services”—those where an extended outage would materially disrupt operations, affect customer funds, or prevent meeting regulatory obligations. Core processors, payment rails, BaaS middleware, primary cloud infrastructure, and card networks typically qualify. Your BIA should drive this list, not a subjective judgment.

Step 2: Vendor BCP collection. Obtain the vendor’s current BCP or continuity summary annually. For critical vendors, request test results, not just a summary attestation. Track the date received and build a refresh cadence.

Step 3: RTO/RPO reconciliation. Match the vendor’s stated recovery capabilities against your institution’s own RTO/RPO requirements. Document any gap—and specifically document your contingency if the vendor’s recovery takes longer than your own target.

Step 4: Write your integration document. This is the missing artifact in most programs. One to two pages per critical vendor: contacts, escalation chain, manual fallback procedures, decision authority for declaring a vendor-related disruption, and the trigger for moving to backup mode. Staff should be able to read and execute this without the vendor being reachable.

Step 5: Notification tracking. Establish a mechanism—even a dedicated email folder—to capture and acknowledge vendor notifications about BCP changes. The booklet requires vendors to notify you; you need evidence you received and processed those notifications. A notification log with date, vendor, change summary, and your disposition is sufficient.

Step 6: Integrate into annual testing. At least annually, include a scenario in your BCM exercise where a critical vendor is unavailable. Document the scenario, what the test revealed, and what gaps require remediation. The testing log is examination evidence.

For a structured kit that includes BIA templates, critical dependency mapping, and tabletop exercise documentation designed to satisfy the FFIEC BCM requirements, the Business Continuity & Disaster Recovery (BCP/DR) Kit provides a starting framework with pre-built documentation for each of these steps.

So What?

The FFIEC BCM booklet’s third-party integration requirement isn’t aspirational guidance—it’s what examiners use to evaluate whether your BCM program has substance behind the binder. Collecting vendor documents satisfies one requirement. Building a combined plan your staff can actually execute when a critical vendor goes dark is what the booklet requires, and what examinations increasingly surface as the gap.

If your last BCM examination or internal audit flagged vendor BCP documentation as a finding, the underlying issue is almost always the integration and testing gap, not the collection gap. The fix isn’t more vendor documents in your folder. It’s one document your institution authored—the integration document—and one evidence file showing you tested what happens when they’re down.

For how sponsor banks currently evaluate fintech partner BCM as part of their own oversight programs, see what your sponsor bank is actually monitoring in 2026.

Sources:

• FFIEC Business Continuity Management Booklet
• FFIEC IT Handbook: Business Continuity Planning in Outsourcing
• OCC Bulletin 2023-17: Third-Party Risk Management Interagency Guidance
• Protiviti: FFIEC BCM Booklet Highlights Operational Resilience Concepts
• Plante Moran: Four Questions from the New BCM Booklet