FINRA Rule 4370 Business Continuity Planning for LLM Provider Outages

Where an LLM provider fits in Rule 4370

Rule 4370 requires each member to create and maintain a written business continuity plan that identifies procedures for an emergency or significant business disruption. The plan must be updated on any material change to the firm's operations, structure, business or location, reviewed annually, and made available promptly to FINRA staff on request. Its elements may be tailored to firm size and needs, but the minimum elements must be addressed, and the rationale for excluding any element must be documented. FINRA's 2025 oversight report also states that the rule applies to denials of service and other interruptions to firms' operations.

The rule does not name LLM providers, and this guide does not treat AI as a new regulatory category. The application is by reasoning from existing obligations. Firms must maintain a supervisory system, including written supervisory procedures, for functions that third-party vendors perform, with Rules 3110 and 4370 given as examples. FINRA's AI guidance lists establishing fallback plans as a consideration, so that a function can continue through an alternative process if an AI application fails through a technical failure or unexpected disruption. An external model API that supports communications review, client service or research summarization fits squarely inside that reasoning.

Two cautions follow. The rule does not mandate testing, only annual review, so any exercises are a firm choice that should be justified by criticality. And the failure scenarios, tiers and fallback routes below are design decisions, not FINRA requirements.

Map the dependency onto the plan

Start with inventory. FINRA's effective practices for third parties include maintaining a list of all vendor-provided services, systems and software components so the impact of a vendor outage can be assessed. For AI, that list should name the LLM provider, the specific models and versions in use, and each supervised function that calls them. Many firms discover the provider is embedded in several workflows owned by different teams.

Then walk each dependency through the plan's elements. The clearest anchor is the element covering critical business constituent, bank and counter-party impact: ask which customers, counterparties and internal supervisory processes are affected if the provider is unavailable or degraded. If you conclude an element does not apply to an AI dependency, record the rationale rather than omitting it silently.

• Add the provider, model versions and dependent functions to the vendor and service inventory.
• Assign an owner for the provider relationship and for contingency assessments.
• Map each function to the relevant plan elements and document any element judged not applicable.
• Define failure scenarios: full outage, regional degradation, high latency, rate limiting, model deprecation and silent output changes.
• Decide what counts as a material change, such as adding a new AI function or swapping a model, and treat it as a possible trigger for a plan update.
• Confirm the current plan and the dependency mappings can be produced promptly on request.

Classify functions and choose fallback behavior

Not every AI-supported function needs the same response. Classify each by the consequence of interruption, then set recovery time and recovery point objectives that match. FINRA's cybersecurity practices suggest aligning these objectives to business criticality and exercising scenarios that rely on manual procedures, which supports tiered fallback design.

Three behaviors cover most cases. Fail closed means the function stops and nothing proceeds without the AI check. It suits functions where an unreviewed output creates supervisory exposure, such as pre-use review of client communications. Human escalation routes the item to a person with a defined queue, staffing assumption and time limit. It suits functions where a reviewer can do the work manually at reduced volume. An alternate route sends the request to a second model under the same policy. It suits lower-risk functions such as internal research summarization, where continuity matters and the output is still subject to review.

Two tradeoffs deserve attention. An alternate model is not equivalent to the primary: it may behave differently, so it needs its own validation under your model risk management process. And human escalation only works if the manual capacity exists, so the queue and staffing need to be tested, not assumed. Silent output changes are the hardest scenario because nothing appears to fail. Decide in advance what monitoring or sampling would reveal a behavior shift and which tier it should push to human review.

Evidence to retain for examiners

No FINRA material defines an evidence package for an AI outage, so this is a design position. The aim is to show two things: what the AI was permitted to do under the plan, and what it did during the disruption. The first is documentation. The second is a record of events, and it is much stronger when captured as the events happen than when reconstructed from scattered application logs afterward.

For the documentation side, keep the current plan and prior versions, the inventory entry for the provider, the criticality tier and fallback decision for each function, and the rationale for any excluded element. For operation, keep exercise or tabletop results including vendor participation and manual procedure scenarios, the failover test outcomes against the control criteria above, and a note on whether the plan was updated afterward. Because the rule requires annual review but not testing, results from any testing you choose to run are the clearest evidence that the plan operated as designed.

For the disruption window itself, retain per-interaction decision records: timestamp, function, route taken, policy applied, and whether the request was allowed, redacted, blocked or escalated, with the approver where a person was involved. These records let you answer an examiner's question about a specific hour on a specific day without relying on after-the-fact log review.

Where runtime enforcement fits

Trussed enforces policy in the execution path between applications and models. Requests are allowed, redacted, blocked, rate limited or escalated for human approval at runtime, not reviewed after the fact. Because the same policy plane covers 100+ models, a request rerouted to an alternate model meets the same requirements as one sent to the primary. The decisions made on each interaction and tool call generate audit-ready evidence as a by-product of enforcement. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

This addresses the control and evidence requirements above. It does not replace the plan itself: criticality tiers, recovery objectives, ownership and the choice between failing closed, rerouting and escalating remain firm decisions. Trussed's scope is individual interactions and tool calls, and it does not provide transaction-level governance or end-to-end tracing of agentic workflows. Examiners and model risk reviewers will still expect the documentation described in the previous section.