Policy analysis demonstrates structural governance gaps in applying banking model risk management to AI code translation, highlighting the need for dedicated transformation frameworks.
Model Risk Management (MRM), set out in the Federal Reserve's SR 11-7 and OCC Bulletin 2011-12, governs quantitative models in banking. AI vendors now offer tools for rewriting production code, including COBOL-to-Java modernization, raising a scope question for the estimation-oriented definition of a model. Through structured assumption-violation mapping, this paper identifies five structural gaps in relying on MRM alone: definition, validation, documentation, monitoring, and third-party risk management. Classifying an underlying LLM as a model leaves a separate task of specifying assurance for the particular software transformation it produces. The paper proposes a complementary Transformation Risk Management (TRM) framework organized around behavioral provenance, scoped functional-equivalence certification, transformation audit trails, rollback architecture, and concentration risk assessment. August 2026 update: The March public version identified the boundary between model risk management and AI-driven code transformation before SR 26-2 was issued on 17 April 2026. The revised guidance expressly excludes generative and agentic AI and points institutions to other risk-management and governance practices. The update preserves the March five-gap analysis and TRM proposal, records that subsequent scope response, and distinguishes the resolved scope-clarification question from the remaining transformation-governance questions.
No takes yet. Share an insight, caveat, or question.
Alex Chengyu Li (2026) studied this question.
Synapse has enriched 5 closely related papers on similar clinical questions. Consider them for comparative context: