Category: Third-Party & Supply Chain

Vendor Model Risk

Also known as: Third-Party Model Risk, Outsourced Model Risk

Simply put

Vendor model risk is the potential for harm that arises when an organization relies on a model built or supplied by an outside party rather than developed in-house. Because the organization may have limited visibility into how the external model works, it can be harder to confirm the model is appropriate, accurate, and being used correctly. This risk is typically managed as part of both model risk management and broader vendor (third-party) risk management activities.

Formal definition

Vendor model risk refers to model risk—commonly understood as the potential for adverse consequences from decisions based on incorrect or misused models—that stems specifically from the use of third-party or externally sourced models, tools, or model components. It commonly encompasses reduced transparency into model design and assumptions, constraints on the organization's ability to independently validate the model, dependence on vendor-supplied documentation and support, and challenges in ongoing monitoring and change control. In many frameworks, vendor model risk sits at the intersection of the institution's model risk management framework and its vendor/third-party risk management program, and it is often addressed through mechanisms such as due diligence, contractual controls, and validation activities adapted to conditions of limited model access. Note that treatment varies by sector and framework; in banking contexts it is frequently discussed alongside supervisory and examination guidance (for example, materials referencing the FFIEC IT Examination Handbook), while enterprise and general AI contexts may frame the same underlying risk differently. The use of the term across sources also varies, with some emphasizing the model risk dimension and others the broader vendor risk lifecycle, so scope should be confirmed against the applicable framework. This entry does not assert that any single regulatory definition applies universally, and controls described here reduce rather than eliminate the underlying risk.

Why it matters

As organizations increasingly source models, tools, and model components from external providers rather than building them internally, a growing share of their model risk originates outside their own development teams. This matters because the potential for adverse consequences from decisions based on incorrect or misused models does not diminish simply because the model was purchased. When an institution has limited visibility into a vendor's design choices, assumptions, and data, it becomes harder to confirm that the model is appropriate for the institution's specific use, that it performs accurately, and that it is being applied correctly—yet accountability for outcomes typically remains with the organization deploying the model, not the vendor supplying it.

Vendor model risk is significant precisely because it sits at the intersection of two management disciplines that are often owned by different teams: model risk management, which focuses on identifying, measuring, monitoring, and controlling risks arising from model use, and vendor (third-party) risk management, which focuses on evaluating and managing risks associated with suppliers and business partners across the relationship lifecycle. When these programs operate in isolation, gaps can emerge—for example, a vendor may be assessed for operational or security risk without the model itself receiving validation adapted to conditions of limited access. In banking contexts, this coordination is frequently discussed alongside supervisory and examination materials, such as those referencing the FFIEC IT Examination Handbook, though the specific expectations vary by sector and framework.

Because treatment of vendor model risk differs across banking, enterprise, and general AI contexts, professionals should confirm scope against the applicable framework rather than assume a single set of requirements applies. The controls commonly used—due diligence, contractual provisions, and validation activities—reduce and manage the underlying risk but do not eliminate it, particularly where reduced transparency constrains independent verification.

Who it's relevant to

Model risk managers and validators

Those responsible for the model risk management framework must extend validation and monitoring practices to externally sourced models, designing approaches that work under limited access—such as outcome analysis and benchmarking—and documenting how vendor-supplied materials factor into their assessment. They also need to coordinate with vendor risk teams so that models are not assessed only for operational or security risk without model-specific scrutiny.

Third-party / vendor risk management teams

Professionals managing the vendor relationship lifecycle—identifying, assessing, and mitigating risks associated with third-party providers—are relevant because model risk is one dimension of vendor risk that requires specialized handling. They typically own due diligence, contracting, and ongoing monitoring, and must interface with model risk functions to ensure the model itself, not just the vendor entity, is evaluated.

Compliance officers and auditors in regulated sectors

In banking and similarly regulated environments, compliance and audit professionals need to understand how vendor model risk maps to applicable supervisory and examination expectations, such as materials referencing the FFIEC IT Examination Handbook. They assess whether the organization's controls demonstrate adequate oversight of outsourced models, while recognizing that specific requirements vary by jurisdiction and framework.

Procurement and legal professionals

Because contractual controls are a common mechanism for managing vendor model risk, those negotiating vendor agreements are relevant to defining provisions around documentation access, support, and notification of model changes. These terms shape how much visibility and control the organization retains, which in turn affects its ability to conduct meaningful validation and ongoing monitoring.

Inside Vendor Model Risk

Third-Party Model Provenance

The origin, development methodology, and data lineage of a model acquired from an external vendor. Because the acquiring organization typically does not control the model's design or training, provenance information is often limited and may need to be obtained through vendor documentation, attestations, or contractual disclosure clauses.

Documentation and Transparency Limitations

Vendor models frequently arrive with reduced access to underlying code, training data, or design assumptions—sometimes described as 'black box' constraints. In many model risk frameworks, this heightens the challenge of independent validation, which can require compensating controls such as outcome analysis and benchmarking.

Validation Under Limited Access

The organization using a vendor model generally remains responsible for validating its fitness for the intended use, even when full internal transparency is unavailable. This commonly relies on conceptual soundness review of available materials, sensitivity or benchmarking analysis, and ongoing outcome monitoring rather than full reconstruction of the model.

Contractual and Governance Controls

Arrangements governing the vendor relationship—such as documentation requirements, audit or information rights, service levels, and change-notification obligations. These sit within AI governance (accountability and oversight structures) and support, but do not substitute for, model risk management activities.

Ongoing Monitoring and Change Management

Processes to detect performance degradation, data drift, or vendor-initiated model updates that may alter behavior. Because the vendor may modify the model outside the user's direct control, monitoring and notification of changes are often treated as distinct control needs.

Concentration and Dependency Considerations

Risks arising from reliance on a single vendor or a widely used shared model, including operational dependency and the possibility that a common model flaw affects many users. These are commonly considered alongside broader third-party and operational risk assessments.

Common questions

Answers to the questions practitioners most commonly ask about Vendor Model Risk.

Does using a third-party or vendor model transfer the associated model risk to the vendor?

No. In many model risk management frameworks, the institution deploying a vendor model retains accountability for the risks arising from its use, even when it did not build the model. Outsourcing development or hosting typically does not outsource responsibility for outcomes, oversight, or regulatory obligations. The vendor relationship adds risk dimensions rather than removing the institution's ownership of them.

Is a vendor model exempt from validation because the institution cannot see the underlying code or proprietary methodology?

Not typically. Limited access to a vendor's internals does not eliminate the expectation to assess the model; it changes the methods used. Where full transparency is unavailable, institutions commonly rely on compensating measures such as outcome analysis, benchmarking, sensitivity testing, review of vendor documentation, and scrutiny of the vendor's own validation evidence. Reduced visibility is generally treated as a factor to manage and document, not a basis for exemption.

How can an institution validate a vendor model when it does not have access to the source code or full development documentation?

When direct code and development access is restricted, validation commonly shifts toward what can be independently observed and tested. This may include outcome and performance analysis on the institution's own data, benchmarking against alternative approaches, sensitivity and stress testing of inputs and outputs, and critical review of any documentation, assumptions, and validation results the vendor provides. The scope and depth typically scale with the model's inherent risk and materiality. Institutions generally document the limitations arising from restricted access.

What should an institution seek to obtain from a vendor to support its own governance and risk assessment?

Institutions commonly seek documentation describing the model's intended use, methodology at an appropriate level of detail, data and assumptions, known limitations, performance results, and the vendor's own testing or validation evidence. Contractual provisions addressing access rights, ongoing support, notification of material model changes, and audit or review cooperation are also frequently pursued. The specifics depend on the model's materiality and the institution's internal requirements, and the available detail may be constrained by the vendor's confidentiality practices.

How does ongoing monitoring differ for vendor models compared to internally developed models?

The core objective of ongoing monitoring is similar for both, but vendor models introduce additional considerations. The institution typically monitors performance on its own data and use context, while also tracking vendor-driven changes such as model updates, retraining, or methodology revisions that it may not directly control. Because such changes can occur on the vendor's timeline, monitoring often includes processes for detecting and assessing them, alongside standard performance and stability tracking. The institution generally remains responsible for identifying degradation regardless of who maintains the model.

How should vendor models be treated within a three-lines-of-defense structure?

In many frameworks, the presence of a vendor does not remove the roles associated with the three lines of defense; it distributes activities differently. The first line typically owns the use and day-to-day management of the vendor model, the second line provides independent oversight and challenge, and the third line provides independent assurance. Vendor-specific tasks—such as due diligence, contract oversight, and monitoring of vendor changes—are generally allocated across these lines rather than delegated to the vendor itself. How responsibilities are assigned can vary by institution and by the model's materiality.

Common misconceptions

Buying a model from a reputable vendor transfers the associated model risk to that vendor.

In many model risk frameworks, the organization deploying a model typically retains accountability for its appropriate use, validation, and monitoring, regardless of who built it. Contractual terms may allocate certain obligations, but responsibility for sound use of the model generally remains with the user.

A vendor model cannot be validated because its internals are not disclosed.

Limited internal access constrains certain validation techniques but does not necessarily preclude validation. Practitioners commonly use compensating approaches such as outcome analysis, benchmarking against alternatives, sensitivity testing, and review of available vendor documentation. The depth achievable, however, may be reduced and should be documented as a limitation.

Vendor risk management and vendor model risk are the same activity.

They overlap but are distinct. Vendor (third-party) risk management addresses the overall supplier relationship, while model risk management focuses specifically on risks arising from the model's design, use, and outputs. A single vendor may raise both, and treating them as identical can leave model-specific risks under-assessed.

Best practices

Establish contractual information and audit rights up front, including access to documentation, disclosure of material model changes, and notification obligations, so that later validation and monitoring are not blocked by access constraints.

Perform and document a validation appropriate to the available level of access, using compensating techniques such as benchmarking, sensitivity analysis, and outcome monitoring where full transparency into the model is not provided.

Explicitly record the limitations of any vendor model assessment—such as reduced visibility into training data or internal logic—so that residual risk is understood by decision-makers rather than assumed to be eliminated.

Implement ongoing monitoring for performance degradation and data drift, and track vendor-initiated model updates that could change behavior, treating change notification as a distinct control from initial validation.

Coordinate model risk management activities with third-party/vendor risk management so that both the supplier relationship and the model-specific risks are covered without collapsing one into the other.

Assess concentration and dependency exposure where a single vendor or a widely shared model is used, and consider contingency or fallback measures for operational continuity.