The Global Risks Alliance (GRA)
Firms use vendor credit scores, fraud models, catastrophe models, market data analytics and foundation models they did not build and cannot fully inspect. Responsibility for model risk stays with the firm. This page sets out how third-party model risk arises, how firms validate what they cannot see, the evidence available, and who decides.
GRA · In development · service level R0
Third-party model risk is the risk from models built by vendors, such as credit scores, fraud models and foundation models, that firms use without full visibility into their design. Responsibility stays with the user. Model risk functions, procurement, supervisors and vendors hold the decisions.
How satellite radar turns a flood into an exposure update. Synthetic scene; no real event or place.
The working screen behind this subject: its structure, terms and states. Names are placeholders and values illustrative.
Third party models · Model inventory · Committee 8
| MD-709 PD retail | Tier 1 | 9 months | 1 | Overdue |
| MD-561 LLM complaints triage | Tier 1 | never | 0 | Not validated |
| MD-601 IFRS 9 staging | Tier 1 | 3 months | 0 | Approved |
| MD-088 marketing propensity | Tier 3 | 14 months | 1 | Approved |
Vendor dependencies and due diligence. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Vendors protect their methods as trade secrets. Firms may get documentation and performance reports but not code, data or training details, which limits validation.
When many firms use the same vendor model, its errors affect them all at once and can move markets or credit supply together.
Vendors update models and data on their own schedules. Without notice and change analysis, a firm's validated model can change silently.
Where internals are hidden, firms validate through benchmarking, outcome analysis and testing on their own data, which needs time and data.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Vendor model | A model developed by an external provider and licensed to a firm. |
| Foundation model | A large AI model trained on broad data that can be adapted to many tasks. |
| Outcome analysis | Comparing a model's outputs with actual results to judge its performance. |
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Third-party models in inventory | count by tier | annual | Model inventory | DECLARED |
| Vendor models with full documentation | share | annual | Vendor management records | DECLARED |
| Vendor model changes notified | count | per year | Vendor notices | REPORTED |
| Third-party models validated on own data | share | annual | Validation records | DECLARED |
| Concentration of vendor model use across firms | share of firms using top vendors | periodic | Supervisory surveys | REPORTED |
| Contracts with model change notice clauses | share | periodic | Contract reviews | DECLARED |
The topic as a computational graph: named sources feed the methods, an evidence review gates the outputs, and the decisions stay with the authorities that hold them.
Fig. 02Nodes carry their type, two metric rows and a state; connectors show what feeds what; dashed frames name the owners; the timeline is the cadence. Design of the pipeline, not a record of a run.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| SR 11-7 guidance on vendor and third-party models | Expectations for using external models | Public domain |
| Interagency guidance on third-party relationships (United States banking agencies) | Third-party risk management expectations | Public domain |
| FSB report on AI financial stability implications | Third-party and concentration risks from AI | Free, FSB terms |
| EU AI Act obligations for providers and deployers | Division of duties between AI providers and users | Free, EU reuse terms |
| Vendor model documentation and performance reports | Information vendors provide to users | Proprietary, terms per vendor |
AI and Financial Model Risk prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Model risk functions | How to validate and approve third-party models | Documentation, benchmarks and outcome testing |
| Procurement and legal | Which transparency and change terms to require | Contract practice and regulatory expectations |
| Supervisors | Whether vendor model use is governed adequately and whether concentration matters | Surveys and review findings |
| Vendors | What documentation and notice to provide | Customer and regulatory requirements |
The questions concern responsibility for models one did not build.
Vendors often protect their models as intellectual property, limiting the transparency available to users. Institutions must still validate the model's use for their own purposes, typically through outcome testing, benchmarking and contractual rights to documentation. Updates by the vendor can change model behaviour without the institution's knowledge.
Concentration is a sector-wide concern. When many institutions use the same vendor model or AI provider, a flaw, outage or change affects them together, creating correlated errors and operational dependencies that no single institution can manage alone.
| Method or data | What it shows | Limits |
|---|---|---|
| Vendor due diligence | Vendor capability, controls and transparency | Limited by vendor disclosure |
| Outcome and benchmark testing | Performance on the institution's own data | Does not reveal internal logic |
| Contract and exit analysis | Rights to information, notification and exit | Rights may be hard to exercise |
| Concentration mapping | Shared dependencies across the sector | Requires aggregated information |
The current service level is R0: information and enquiries. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.