A global asset manager licenses a third-party AI platform from a fintech vendor to generate portfolio risk scores. The vendor refuses to disclose model architecture details, citing proprietary concerns. Under SR 11-7 and OCC Bulletin 2013-29 on third-party risk management, which approach best satisfies the asset manager's model risk obligations?

SR 11-7 explicitly states that a financial institution's use of vendor-developed models does not transfer model risk responsibility to the vendor. The user institution — in this case the asset manager — remains accountable for understanding, validating, and monitoring any model it relies on for material business decisions, including third-party systems.

The guidance acknowledges that vendors may restrict access to proprietary model internals. In those cases, regulators expect institutions to employ compensating measures: conducting independent outcome analysis (back-testing model outputs against realized risk events), performing benchmarking against alternative models or simpler proxies, and stress-testing model outputs under hypothetical scenarios. Conceptual soundness reviews can often be completed using vendor white papers, academic references cited by the vendor, and challenger model comparisons even without full code access.

OCC Bulletin 2013-29 adds the third-party risk management dimension: institutions must negotiate contractual provisions that provide audit rights, performance reporting requirements, and notification of material model changes. A vendor's refusal to support any oversight mechanism is itself a risk escalation trigger.

Options A and C misread both bulletins — neither creates a vendor-exemption carveout. Option D conflates IT security certification (SOC 2) with model risk validation; a SOC 2 report addresses data security controls, not model conceptual soundness or predictive performance. CFIA candidates must understand that model risk governance is a use-case obligation, not a developer obligation.