Answer capsule
Buying a model does not transfer the finance leader's responsibility to understand its purpose, limits, performance, and fit for the decision it supports.
What the source establishes
- SR 26-2 says covered banking organizations should apply model-risk principles to vendor and third-party models.
- The guidance expects sufficient information to understand a model's conceptual soundness, design, development data, limitations, and intended use.
- Vendor models remain subject to validation, ongoing monitoring, outcomes analysis, and documentation proportionate to their materiality.
- SR 26-2 expressly excludes generative and agentic AI models from its supervisory definition of a model.
Put the purchase inside the model inventory
A procurement record is not a model record. For a covered vendor model used in planning, liquidity, reporting, valuation, or control work, finance should be able to identify the exact version, business purpose, decision owner, inputs, outputs, dependencies, materiality, and approved limits of use. Link the contract and vendor documentation to that inventory entry, but do not let them replace it. The useful test is whether an independent reviewer could reconstruct what finance relied on, why the model was suitable for that use, and what would cause its use to be restricted or stopped.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Treat limited transparency as a risk condition
A vendor may protect intellectual property or decline to expose every implementation detail. SR 26-2 does not turn that commercial constraint into evidence of soundness. Finance can record what the vendor supplied about theory, design, development data, performance, limitations, and change management; identify what remains unavailable; and decide whether testing, contractual rights, use restrictions, or compensating controls make the residual uncertainty acceptable. If the organization cannot obtain enough information to understand the model for its intended use, that gap belongs in the approval decision rather than in a footnote after deployment.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Validate the configured use, not the brochure
Vendor benchmarks describe a product under selected conditions. They do not establish performance on the institution's data, configuration, thresholds, overrides, integrations, or decision process. Validation should examine the conceptual basis and the observed results for the actual use, then continue through monitoring and outcomes analysis. Material customizations need documentation, and vendor changes need a route back through change control. The CFO should see who owns performance review, which indicators reveal deterioration, how exceptions are escalated, and whether several vendor models create a concentrated dependency across the finance portfolio.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Keep the scope boundary explicit
This source offers a strong discipline for covered vendor models, but it does not place generative or agentic AI inside SR 26-2. A finance copilot or action-taking agent still needs an evidence record for data access, retrieval, instructions, tool permissions, approvals, evaluation, incidents, and retirement under the controls and obligations that actually apply. Teams may borrow useful questions from model-risk practice, provided the record labels them as internal design choices rather than supervisory compliance. That distinction lets finance demand serious vendor evidence without making an assurance claim the source expressly does not support.
The accountable team should translate this point into a named workflow, affected population, source data, human owner, approval right, exception path, retained evidence, and review date. That translation is what separates an interesting AI development from a decision that can be governed and evaluated.
Decision test
Ask whether the source changes the decision itself, the evidence required, the implementation sequence, or only the language used to describe an existing capability. Record which claims are directly supported, which are provider statements, which require an independent test, and which remain unknown. A source-linked review should make uncertainty easier to see, not bury it inside a blended score.
Questions to take into review
- Which planning model and dimensions ground the answer?
- Can every assumption be traced to an owner and date?
- What is the freshness and completeness of each cash source?
- How are restricted cash and intercompany balances treated?
- Which source supports each number and assertion?
- How is materiality assessed outside the model?
- Is the AI itself in scope for change and access controls?
- Can evidence provenance survive export and retention?
The publication supports research and executive decision preparation. It does not provide legal, financial, accounting, employment, clinical, cybersecurity, investment, procurement, or implementation advice.