We publish the framing. We retain the machinery.
Three artifacts, open and free to use. If they are useful, take them into your own programme — you do not need to engage us to benefit from them. That is the point of publishing them.
Asset 01 — Regulatory Crosswalk
Twelve E-23 principles, mapped to the frameworks you already report against.
Guideline E-23 takes effect 1 May 2027 — roughly 9 months away. Most institutions already hold NIST AI RMF or ISO/IEC 42001 artifacts. The question is what carries over and what does not.
Enterprise-wide model risk management
Model risk is well understood and managed across the enterprise.
Risk-based approach
Model risk is managed using a risk-based approach.
Model lifecycle management
Model governance covers the entire model lifecycle.
Provenance
The three outcomes, twelve principles and principle statements above are taken from OSFI Guideline E-23 – Model Risk Management (2027), published 11 September 2025, effective 1 May 2027.
SR 26-2 references are to the US interagency Supervisory Guidance on Model Risk Management issued 17 April 2026, which supersedes SR 11-7 (2011) and SR 21-8. Section numerals are that document’s own.
The cross-framework mappings are Aegis interpretation, not regulator-issued equivalences. No standards body publishes an official concordance between E-23, NIST AI RMF, ISO/IEC 42001, SR 26-2 and the EU AI Act. We publish ours so it can be challenged; your second line should satisfy itself independently before relying on it.
What SR 26-2 does not cover
“Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance. Nonetheless, a banking organization’s risk management and governance practices should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document. However, the principles described in this guidance apply to traditional statistical and quantitative models and non-generative, non-agentic AI models.”
SR 26-2, Supervisory Guidance on Model Risk Management, footnote 3
The agencies have said they intend to issue a request for information covering model risk management generally and banks’ use of AI, including generative and agentic AI. Until that produces guidance, the governance determination for these systems rests with the institution.
The practical consequence: a generative or agentic system sits outside the guidance your model risk function works to, while remaining squarely inside your own governance obligation. Whichever way an institution resolves that, the resolution needs to be a documented determination rather than an omission.
Read the guidance — footnote 3 is on page 3Asset 02 — Reference Architecture
Governed private LLM, with the evidence on the path.
Most reference architectures put governance beside the pipeline as a reporting layer. This one puts evidence emission points E1–E6 directly on the request path, so audit evidence is a by-product of running the system rather than something assembled before an exam.
E2 — Policy & Entitlement
This is where the traceability spine attaches. The control identifier and the model risk tier are bound to the request before anything is retrieved or inferred.
Evidence emitted: Control ID + risk tier stamped on the request
Asset 03 — AI System Inventory Schema
The seventeen fields E-23 requires you to track.
Appendix 1 of the guideline sets a minimum information tracking standard: six fields for every identified model, eleven more for any model carrying non-negligible inherent risk. This is the inventory a supervisor will ask to see.
model_idcorePrimary key across the estatemodel_namecorePlus description of key features and usemodel_risk_ratingcoreFrom the tiering rubric (Principle 2.2)model_ownercoreAccountable unit or individualmodel_developercoreUnit or individualmodel_origincoreInternally developed or vendormodel_versionextendedBound to a deployed artifactdeployment_dateextendedDate moved into productionmodel_reviewerextendedIndependent of the developermodel_approverextendedAuthority that approved usemodel_dependenciesextendedUpstream models, libraries, servicesdata_sourcesextendedWith description — ties to lineageapproved_usesextendedScope boundary for the modelmodel_limitationsextendedIncluding exceptions and conditionslast_review_dateextendedMost recent independent reviewmonitoring_statusextendedWith exceptions as applicablenext_review_dateextendedDrives the review calendarThe field list is authoritative — it is Appendix 1 of Guideline E-23. The snake_case naming and the core/extended split are our schema convention. The machine-readable version, with types, enumerations and validation rules, is released to clients under engagement.
Why we give this away
The crosswalk is not the moat.
A populated inventory, a working capacity model, and a traceability spine that actually binds a control identifier to a compute partition — those take an engagement. The framing does not, so we publish it.
Book a qualification call