Skip to main content
Bureau of AI
Category: Third-Party & Supply Chain

Outsourced Models

Also known as: Third-Party Models, Vendor Models, Externally Developed Models
Simply put

Outsourced models are models that an organization obtains from an external party rather than building in-house, such as tools purchased from a vendor or supplied by a service provider. The organization still uses these models to make or support decisions, so it remains responsible for understanding how they work and managing the risks they create, even though it did not develop them. Because much of the internal knowledge about the model sits with the third party, obtaining sufficient information for oversight is often a central challenge.

Formal definition

In model risk management, 'outsourced models' typically refers to models developed, supplied, or operated by third parties—including vendor products, service-provider models, and externally built components—that an institution deploys within its own decision processes. As commonly framed, the use of an external provider does not transfer accountability for model risk: the adopting organization generally remains responsible for validating fitness for its intended use, monitoring ongoing performance, and applying controls, subject to the practical constraint that vendors may limit access to proprietary methodology, data, or code. The scope and treatment of outsourced models are context-dependent and can differ materially between regulated banking environments and general enterprise AI settings; this entry does not assert a single authoritative definition, and the specific meanings of 'outsourcing model' in unrelated commercial domains (for example, IT, trading, or marketing outsourcing arrangements) are out of scope.

Why it matters

Outsourced models create a distinctive risk-management challenge because accountability and knowledge become separated. As commonly framed in model risk management, an institution that adopts a vendor or service-provider model remains responsible for managing the risks that model introduces into its decisions, yet much of the detailed understanding of methodology, data, and code sits with the external provider. This asymmetry means an organization can be held accountable for outcomes it cannot fully inspect, making the sufficiency of information obtained for oversight a recurring central concern.

The stakes are heightened where outsourced models feed decisions with regulatory, financial, or consumer consequences. Because vendors may treat their approaches as proprietary, institutions can struggle to validate fitness for their specific intended use and to monitor ongoing performance—two activities that are not discharged simply by relying on the vendor's own testing. Treating a purchased model as a black box that requires no independent scrutiny is a common error; the fact that a model was not built in-house does not, in most frameworks, transfer the underlying responsibility for its risks.

The appropriate treatment of outsourced models is context-dependent and can differ materially between regulated banking environments and general enterprise AI settings. Because there is no single authoritative definition across all contexts, professionals should be cautious about assuming that expectations from one domain apply unchanged to another.

Who it's relevant to

Model Risk Managers and Validators
Those responsible for model risk must determine how to validate and monitor models they did not build, often working with limited access to proprietary methodology or code. They typically design compensating approaches—such as outcome testing and benchmarking—to assess fitness for the intended use despite these constraints.
Vendor and Third-Party Risk Teams
Teams managing third-party relationships help secure the information, documentation, and contractual terms needed for oversight. Because much of the model knowledge sits with the provider, negotiating access and defining reporting obligations is central to their role.
Compliance Officers and Auditors
Compliance and audit functions assess whether the organization has retained and exercised its responsibility for outsourced models rather than assuming accountability transferred to the vendor. They also consider that expectations may differ between regulated banking and general enterprise AI contexts.
Business Owners Deploying Vendor Models
Business units that adopt purchased or externally supplied models make or support decisions using tools they did not develop. They need to understand the model's limitations and the controls required, since using a vendor model does not remove responsibility for the risks it creates.

Inside Outsourced Models

Third-party or vendor-supplied models
Models developed, wholly or partly, by an external party rather than in-house. These include purchased analytical tools, vendor scoring engines, and models embedded in software procured from suppliers. The defining feature is that the developing organization is not the deploying organization.
Reduced transparency into model construction
Outsourced models often function as limited-visibility or 'black box' arrangements where the vendor may not disclose proprietary methodology, training data, or assumptions. This constrains the depth of independent validation the deploying institution can perform.
Retained accountability by the deploying institution
In many frameworks, including supervisory guidance such as SR 11-7 as commonly interpreted for banking, the institution using an outsourced model typically remains accountable for the risks it introduces, regardless of who built it. Outsourcing the development does not, as generally understood, outsource the ownership of the resulting model risk.
Vendor risk and governance overlap
Outsourced models sit at the intersection of model risk management and broader third-party or vendor risk management. The governance component covers contractual terms, oversight responsibilities, and escalation paths, while the model risk component covers validation, monitoring, and control of the model itself.
Contingency and exit considerations
Because the deploying institution does not control the model's ongoing development, arrangements commonly address vendor discontinuity, version changes, and fallback plans should the vendor cease support or the model become unavailable.
Validation constraints and compensating measures
Where full validation is not feasible due to limited access, institutions typically apply compensating controls such as outcomes analysis, benchmarking against alternative models, sensitivity testing, and heightened monitoring of inputs and outputs.

Common questions

Answers to the questions practitioners most commonly ask about Outsourced Models.

Does outsourcing a model transfer responsibility for its risks to the vendor?
No. In many model risk management frameworks, accountability for the risks arising from a model's use typically remains with the organization deploying it, regardless of who developed or hosts the model. Contractual arrangements may allocate certain obligations to the vendor, but the deploying institution generally retains responsibility for validating, monitoring, and controlling the model within its own environment. Outsourcing changes how risk is managed, not who ultimately answers for it.
Is a vendor's own validation sufficient to satisfy the organization's model validation obligations?
Not necessarily. Vendor-supplied validation or documentation can be an input, but it does not generally replace the deploying organization's own independent review. As commonly framed in model risk guidance, the institution is expected to assess whether the model is appropriate for its specific use, data, and risk appetite. Where vendor documentation is limited by proprietary constraints, organizations typically compensate with alternative evidence such as benchmarking, outcome analysis, or enhanced monitoring rather than treating the vendor's assurances as conclusive.
What information should an organization seek from a vendor to support validation of an outsourced model?
Organizations typically seek documentation on the model's intended purpose, methodology, assumptions, limitations, development and testing data, and known performance boundaries. Where full disclosure is constrained by proprietary interests, professionals often negotiate access to summary methodology, validation reports, or the ability to conduct independent testing. The sufficiency of this information depends on the model's inherent risk and the use case; higher-risk applications generally warrant more extensive evidence.
How can an organization monitor an outsourced model when it does not control the underlying development?
Monitoring commonly focuses on the aspects the organization can observe: input data quality, output behavior, performance against benchmarks, and outcomes over time. Because the institution may not be notified of vendor-side changes, monitoring arrangements are often paired with contractual provisions requiring the vendor to disclose material model updates, retraining, or version changes. This helps distinguish genuine performance degradation from changes introduced by the vendor.
What role do contracts play in managing outsourced model risk?
Contracts are frequently used to define expectations around documentation access, notification of model changes, service levels, data handling, audit or review rights, and support during incidents. They do not eliminate the organization's underlying risk-management obligations, but they can establish the mechanisms through which oversight is exercised. The adequacy of contractual terms is generally assessed relative to the model's risk profile and the criticality of its use.
How does the three-lines-of-defense structure apply to outsourced models?
In many organizations, the business unit deploying the outsourced model sits in the first line and owns day-to-day use and monitoring; the second line, such as a model risk or compliance function, sets standards and provides independent challenge, including over vendor selection and validation adequacy; and the third line, typically internal audit, provides independent assurance over the overall process. Outsourcing does not remove any of these lines; it shifts some activities toward oversight of the vendor relationship rather than direct control of the model's construction.

Common misconceptions

Using a vendor model transfers the associated model risk to the vendor.
In many supervisory and governance frameworks, accountability for managing the risk of a deployed model typically remains with the institution using it. Outsourcing development does not, as commonly understood, transfer ownership of the resulting model risk, though contractual terms may allocate certain responsibilities between the parties.
Vendor models cannot be validated because their internals are proprietary.
Limited access constrains but does not eliminate validation. Practitioners commonly rely on compensating approaches such as outcomes analysis, benchmarking, and sensitivity testing. Reduced transparency is a limitation to document and manage, not a basis to forgo independent scrutiny.
A well-known or widely adopted vendor model requires less governance oversight.
Vendor reputation or market adoption does not substitute for institution-specific validation and monitoring. A model's suitability depends on the deploying institution's data, use case, and risk appetite, which are typically outside the vendor's assessment.

Best practices

Establish contractual terms that address access to information, documentation, version changes, notification of material updates, and support obligations, so oversight is not dependent solely on vendor discretion.
Apply compensating controls where full validation is not feasible, including outcomes analysis, benchmarking against alternative models, sensitivity testing, and heightened input and output monitoring.
Document the limitations of the validation performed, explicitly noting where reduced transparency prevented independent assessment of methodology, data, or assumptions.
Coordinate model risk management with vendor or third-party risk management functions so the governance and model-specific responsibilities are clearly assigned and not left in a gap between the two.
Maintain contingency and exit arrangements that address vendor discontinuity, unavailability, or unexpected version changes, including identified fallback options.
Treat the deploying institution as retaining accountability for the model's risk, and reflect that ownership in monitoring intensity and internal reporting rather than deferring to vendor assurances.