Machine learning third-party risk management for a bank means running two oversight tracks on the same vendor relationship at once: the June 2023 interagency guidance’s third-party lifecycle, which assesses the vendor itself, and SR 26-2’s model validation expectations, which assess the model the vendor supplies, regardless of who built it. A vendor questionnaire that checks SOC 2 reports and financial condition satisfies the first track and says nothing about whether the credit, fraud, or pricing model that vendor delivers actually performs on your own data. Most banks staff one track well and treat the other as implied. Neither guidance lets you treat a vendor-supplied model as less than a model in your own inventory.
This guide is for the Chief Risk Officer, the head of model risk, and the head of third-party or vendor risk at a bank, captive finance arm, or fintech that buys machine learning models rather than builds every one internally: a credit scorecard from a decisioning platform, a fraud model embedded in a payments processor, an AML transaction-monitoring engine, or a pricing or underwriting model licensed from a specialty vendor. It is a practitioner framework, not legal or regulatory advice, and it assumes your program already has some third-party risk process and some model validation process; the gap this guide addresses is where those two processes fail to meet in the middle on the same vendor.
Want to put this into practice? Use our AI vendor due-diligence questionnaire.
Why a machine learning vendor is not a typical AI vendor
A generic AI vendor risk review, the kind that covers a chatbot platform, a drafting copilot, or a document-summarization tool, asks mostly third-party questions: how does the vendor govern its own AI program, how does it handle your data, what are its sub-processor dependencies, will it tell you when it changes the underlying model. Those questions matter, and DSE’s AI vendor risk assessment checklist for banks and fintechs and AI vendor risk management program cover that lifecycle in full.
A machine learning model vendor adds a second, independent obligation on top of that lifecycle. When the thing you are buying is a model that drives a credit decision, a fraud flag, a loan price, or a suspicious-activity determination, that model falls inside your model risk management program’s scope the moment it goes into production, whether your bank wrote a line of its code or not. SR 11-7 established, and SR 26-2 carries forward, that a vendor’s ownership of the model’s internals does not reduce the bank’s obligation to validate it. You cannot contract your way out of model validation, and a vendor’s own testing, however rigorous, is not a substitute for your model risk function’s independent review.
That means a machine learning vendor relationship needs both tracks running, not one standing in for the other:
- The third-party track assesses the vendor as a business and a counterparty: financial condition, information security, business continuity, concentration risk, and the five-stage relationship lifecycle the June 2023 interagency guidance describes.
- The model risk track assesses the model as a model: conceptual soundness, outcomes analysis on your own population, ongoing performance monitoring, and a validation cadence tied to the model’s risk tier, exactly as SR 26-2 requires for a model your own data scientists built.
A program that runs only the first track has a vendor file but no evidence the model works on your borrowers, your transactions, or your claims. A program that runs only the second has validation results but no visibility into whether the vendor’s financial health, sub-processor exposure, or concentration risk could take the model offline or change it without notice.
What SR 26-2 actually asks for on vendor models
SR 26-2 does not create a separate, lighter standard for externally sourced models. It asks the same three things of a vendor model that it asks of an internally built one: a documented assessment of conceptual soundness, ongoing monitoring of performance against expected outcomes, and an outcomes analysis that compares what the model predicts to what actually happens. The practical difference is method, not standard. A bank rarely has access to a vendor model’s training data, feature weights, or architecture, so the validation function substitutes techniques that do not require that access: benchmarking the vendor’s outputs against an independent model or a simpler baseline, sensitivity analysis on the inputs the bank controls, and outcomes analysis run entirely on the bank’s own population rather than the vendor’s development sample.
This is where the two tracks have to hand off information to each other, and where most programs lose the thread. The third-party risk team is usually the first to learn that a vendor has updated its model, swapped a sub-processor’s underlying model, or retrained on a new data vintage, because that information surfaces through contract management, vendor check-ins, or a change notification clause. If that information never reaches the model risk function, the bank is running a validation schedule against a model that no longer exists in production. The contract clause matters here in a specific way: a notice-of-material-model-change provision is not a third-party risk formality, it is the trigger that tells the model risk function a re-validation is due.
Mapping the interagency lifecycle to model-specific requirements
The five-stage lifecycle in the June 2023 interagency guidance was written for third-party relationships generally. Applied to a machine learning model vendor, each stage carries a model risk task that a generic third-party review will not surface on its own.
| Lifecycle stage | Standard third-party task | Model-specific task it needs alongside it |
|---|---|---|
| Planning | Define the business need and risk level of the relationship | Classify the vendor’s deliverable as a model under your model risk framework before the vendor search starts, so model risk has a seat in the requirements |
| Due diligence and selection | Assess the vendor’s financial condition, security, and operational capacity | Obtain enough transparency into methodology, training data provenance, and intended use to support an initial conceptual soundness review; a vendor that will not disclose any of this is a validation risk, not just a disclosure risk |
| Contract negotiation | Negotiate SLAs, audit rights, and data use terms | Add explicit terms for notice of material model changes, ongoing access to performance data needed for monitoring, and audit rights that extend to model behavior, not only to security and operations |
| Ongoing monitoring | Track vendor performance, financial health, and incident history | Run an independent outcomes analysis against the bank’s own population on a cadence matched to the model’s risk tier, and re-validate on any material model change the vendor reports |
| Termination | Plan transition and data return at contract end | Confirm the bank retains enough historical performance data and documentation to support any models still relying on the vendor’s outputs, or to validate a replacement model against the same baseline |
The column on the right is the work a third-party risk questionnaire does not ask for by default, and it is the column an examiner reviewing a model risk program will ask about directly.
The gap DSE finds most often
In practice, the failure mode is organizational before it is technical. Third-party risk and model risk sit in different reporting lines at most banks, run different questionnaires, and meet only when a vendor relationship is large enough to force a joint review. A mid-sized credit decisioning vendor, a fraud-scoring add-on bundled into a payments platform, or a regional AML tool often clears third-party risk’s vendor tiering without ever reaching the threshold that triggers a joint review, and the model never gets logged in the model inventory at all. The vendor file looks complete. The model risk function has never seen it.
The second most common gap is the reverse: a model risk function validates a vendor model thoroughly at onboarding, using whatever benchmarking and outcomes analysis the limited transparency allows, and then has no process for learning the vendor retrained the model eighteen months later. The validation on file describes a model no longer running in production, and nobody in the loop knows it changed until a performance drift shows up or an examiner asks for the validation date against the current model version.
Both gaps have the same fix: the vendor inventory and the model inventory need to be the same inventory, with a single record per vendor-supplied model that both functions update, and a change-notification clause that routes directly to model risk, not just to whoever manages the contract.
Fourth-party and training-data provenance risk
A machine learning vendor’s own dependencies extend the risk surface further than a typical SaaS vendor’s do. Three questions are specific to ML vendors and belong in due diligence alongside the standard fourth-party review: whether the vendor’s model relies on a foundation model or base model licensed from another provider, so a change at that upstream layer can change your model’s behavior without your vendor changing anything on their end; whether the vendor can describe, even at a high level, the provenance of its training data, since a model trained on data the vendor does not have clear rights to use carries that exposure forward into your decisioning process; and whether the vendor has tested the model for disparate impact across protected classes on data resembling your population, since a vendor’s own fair lending testing on its development sample does not substitute for your bank’s own testing obligation under ECOA and Regulation B once the model drives a credit decision for your customers.
None of this replaces the fair lending, UDAP, or GLBA obligations that already apply once a vendor model touches a credit or financial decision. It gives the model risk function’s conceptual soundness review a documented basis to stand on when the vendor will not share methodology details.
Questions buyers ask
Does SR 26-2 apply to a model we license rather than build ourselves?
Yes. SR 26-2 continues SR 11-7’s position that a vendor’s ownership of a model’s internals does not reduce the bank’s obligation to validate it. The validation method adapts to limited transparency, relying on benchmarking, sensitivity analysis, and outcomes analysis run on the bank’s own data rather than access to the vendor’s training data or code, but the standard, conceptual soundness, ongoing monitoring, and outcomes analysis, is the same one applied to an internally built model.
Isn’t a vendor’s own model validation report enough?
No. A vendor’s internal testing, however rigorous, is not a substitute for the bank’s own independent validation, because the vendor’s testing was run on its own development sample and cannot speak to how the model performs on your specific borrowers, transactions, or claims. A vendor’s validation documentation is useful supporting evidence for your conceptual soundness review, not a replacement for your outcomes analysis.
Our third-party risk team already reviews every AI vendor. Why isn’t that enough for a machine learning vendor?
Because a third-party risk review answers whether the vendor is a sound counterparty, not whether the model the vendor supplies performs correctly on your data. A vendor can pass every security, financial, and operational check in the June 2023 interagency lifecycle while the model itself has never been validated against your portfolio. Both reviews are required, and they answer different questions.
What is the single most common finding in machine learning third-party risk reviews?
A vendor-supplied model that is current in the third-party vendor inventory but missing from the model risk inventory, or a model that was validated once at onboarding with no process for learning when the vendor retrains or updates it. Both leave the bank holding a validation record that no longer describes the model in production.
Can DSE certify that our machine learning vendor program satisfies SR 26-2 and the interagency third-party guidance?
No. DSE prepares programs for audit and examination by building the joint vendor-and-model inventory, the due diligence and contract terms specific to ML vendors, and the validation evidence an examiner expects, and the result is audit-ready and supervisory-framework-aligned. DSE does not certify compliance or guarantee any examination outcome; that determination rests with your examiners and your own model risk and third-party risk functions.
The Bottom Line
Machine learning third-party risk management is not a heavier version of a standard AI vendor review, it is two reviews, the June 2023 interagency third-party lifecycle and SR 26-2 model validation, run against the same vendor relationship with one shared inventory record instead of two disconnected files. The gap DSE finds most often is organizational, not technical: a vendor model that clears third-party risk’s tiering without ever reaching model risk, or a validated model that quietly changes under the vendor’s own retraining schedule with no notice clause routing that change back to validation. Closing that gap starts with the contract terms and the inventory record, not with a heavier questionnaire.
Building the joint vendor-and-model inventory, the ML-specific due diligence questions, and the validation cadence this review needs is exactly the work our AI vendor risk review engagement runs for banks, captive finance arms, and fintechs. Start with the AI governance checklist to see where your current vendor and model inventories stand, or review finserv compliance for the broader financial-services compliance picture.
Key facts
- The June 2023 Interagency Guidance on Third-Party Relationships: Risk Management, issued jointly by the OCC, Federal Reserve, and FDIC, frames third-party risk across a five-stage lifecycle of planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination, and it applies to a machine learning model vendor the same way it applies to any other third party (DSE, 2026).
- SR 11-7 held that a bank's use of a vendor-developed model does not reduce the importance of validation, and SR 26-2, which superseded SR 11-7 on April 17, 2026, continues that expectation by naming vendor and third-party model controls as one of its explicit scope items (DSE, 2026).