Model risk management frameworks in banking rest on a simple premise: a model used in decision making should be understood, tested and monitored by the institution that relies on it. Supervisory guidance in the United States and comparable expectations elsewhere apply that premise whether the model was developed internally or purchased, and they place responsibility on the user institution rather than the vendor.
That creates an uncomfortable dependency. The validation team needs documentation of methodology, testing, assumptions and limitations. It needs to know when the vendor changes the model or its training data. It needs the ability to run outcomes analysis on the institution’s own portfolio. None of this is available unless the agreement says so, and standard vendor terms for analytics and scoring products frequently say the opposite, treating methodology as confidential and reserving the right to change the service at will.
The gap usually surfaces during an examination or an internal audit rather than at purchase. Procurement negotiated price, service levels and data protection competently. Nobody asked whether the validation function would be able to assess conceptual soundness, and by then the contract is signed and the model is in production supporting credit, pricing or surveillance decisions.
Where purchased model agreements fall short
The same handful of gaps appears across pricing models, credit scorecards, fraud and surveillance engines and third-party analytics embedded in larger platforms.
- Methodology behind a confidentiality wall, the vendor will describe inputs and outputs but not the approach, which makes an assessment of conceptual soundness impossible on the evidence available.
- No change notification duty, the model is retrained or recalibrated on the vendor’s schedule, the institution learns afterward, and the validation conclusion silently expires.
- Testing evidence unavailable, performance claims are marketing figures rather than documented testing on defined populations, with no stated limitations or known weaknesses.
- No benchmarking or challenger rights, the agreement does not permit the institution to run comparative analysis, or restricts use of outputs in ways that block it.
- Exit terms cover data, not documentation, on termination the institution recovers its own data and loses the model documentation it needs to explain historic decisions.
These are contract design problems with contract design answers. The validation function knows exactly what it needs, and it is rarely consulted before signature. Building the requirement into the intake questionnaire is the cheapest available fix, and it belongs in the same control framework that already governs third-party risk contract automation.
Vendors reasonably resist disclosing proprietary methodology in full, and most validation work does not require it. Workable middle positions exist: documentation sufficient to describe the approach and its limitations, review under supervised conditions at the vendor site or through a secure environment, a third-party validation report the institution may rely on, or access to testing results on defined populations. Negotiating the mechanism is far more productive than arguing about the principle.
Five obligations that make a purchased model governable
Each needs a response time and an owner, because validation cycles and examination requests both run to deadlines.
- Documentation delivery and refresh. A defined documentation package delivered at implementation and refreshed on a stated cycle, covering approach, data, assumptions, limitations and known weaknesses.
- Validation access mechanism. A named route for the validation function to examine methodology and testing evidence, whether on site, through a secure environment, or via a reliance report, with a response time attached.
- Material change notification. Advance written notice before changes to methodology, training data, calibration or scope, with enough lead time for the institution to reassess before the change takes effect.
- Outcomes analysis and benchmarking rights. Express permission to run performance monitoring, back-testing and challenger comparisons using the institution’s own data, without restrictions that make the analysis unusable.
- Continuity and exit provisions. Retention of documentation and historic outputs after termination, sufficient to explain and defend decisions made while the model was in use.
A five-step roadmap for contracting purchased models
Step 1, Identify which purchases are models before procurement starts
Many are not labeled as such. Scoring services, pricing engines, optimization tools and analytics embedded inside platforms all behave as models. A short screening question at intake, asking whether the tool produces an estimate or a decision input, catches most of them.
Step 2, Give the validation function a seat before signature
Convert the validation requirements into a short standard annex and a set of questions for diligence. The annex is what lets procurement negotiate from a known position instead of discovering the requirement after the fact.
Step 3, Negotiate the access mechanism explicitly
Choose among on-site review, secure environment access, reliance on a third-party validation report, or delivery of testing results by population. Write the chosen mechanism into the agreement with a response time, rather than relying on a general cooperation clause.
Step 4, Tie change notification to the validation cycle
The notice period should be long enough for the institution to reassess before the change reaches production. Where the vendor cannot offer that, agree compensating controls such as enhanced monitoring thresholds, and record that decision with the model.
Step 5, Register the recurring duties and monitor them
Documentation refresh dates, notification obligations, annual reporting, validation access requests and exit retention periods all belong in the obligation register with owners and dates, so the control operates between examinations rather than during them.
See vendor model obligations tracked to dates
Documentation refresh cycles, change notices and validation access requests monitored with owners, evidence and response times.
Why the obligation register matters more than the clause
A well-drafted model risk annex creates duties that recur: documentation refreshed annually, notifications delivered before changes, testing evidence supplied on request within a stated window, attestations provided each year. Those duties are performed by the vendor and monitored by the institution, and monitoring is where the control usually fails. The clause exists, nobody tracks whether the refresh arrived, and two years later the documentation on file describes a model version no longer in production. The remedy is mechanical. Every recurring duty becomes a register entry with a named owner, a due date and an evidence artifact, and missed entries escalate like any other control exception. Institutions that run this well can answer an examiner question about a purchased model in hours rather than weeks, because the evidence trail is a byproduct of the monitoring rather than a reconstruction exercise. The pattern is the same one used for vendor contract file completeness.
Mapping validation needs to contract terms
The table below pairs each validation requirement with the contractual mechanism that satisfies it and the artifact that evidences performance.
| Validation need | Contract mechanism | Cadence | Evidence |
|---|---|---|---|
| Conceptual soundness assessment | Documentation package with limitations stated | At implementation and annually | Versioned documentation set |
| Methodology review | Named access route with response time | On request | Review record and vendor response |
| Ongoing monitoring | Outcomes analysis and benchmarking rights | Quarterly or per policy | Monitoring reports on own data |
| Change control | Advance material change notification | On vendor change event | Notice with effective date |
| Decision defensibility | Post-termination documentation retention | On exit | Retained documentation and outputs |
Purchased models are not a way to outsource model risk. The institution keeps the responsibility and acquires a dependency, and the agreement determines whether that dependency is manageable. The institutions that handle it well screen for models at intake, involve the validation function before signature, negotiate a specific access mechanism rather than a general cooperation promise, tie change notice periods to their own reassessment cycle, and track every recurring vendor duty in an obligation register with owners and dates. None of that requires the vendor to surrender proprietary methodology. It requires the institution to decide what it needs before it signs, and to keep checking that it arrives.
For related guidance, see DORA and ICT contracts: what Article 30 requires, OCC and FFIEC vendor oversight, the contract controls and Tracking obligations in syndicated loan fee letters.
