Model Risk Management at Fannie Mae
Enterprise model lifecycle governance, regulator-aligned and audit-ready

Problem
At Fannie Mae, tracking a model's full lifecycle meant hunting through spreadsheets, SharePoint folders, and whatever a teammate remembered. Registration, version history, validation checks, findings, sign-offs, and renewals were scattered across disconnected tools — so when regulators asked whether a model was safe, compliant, and traceable, no one could prove it easily. MUSE was designed to bring the entire model lifecycle into one platform where every action is recorded, every role has clear permissions, and auditors can follow the trail from intake to retirement without digging through emails or notebooks.
What is a model lifecycle?
In banking, a model is any system that uses math or data to make decisions that affect customers or the business — like predicting loan defaults, setting interest rates, or detecting fraud. Because these decisions can have serious consequences, regulators require banks to prove every model is sound, properly tested, and used only in ways it was approved for. A model's lifecycle starts when someone registers it, then it goes through independent validation, gets activated for use, and must be revalidated regularly until it is retired. If a model changes, fails a test, or is used outside its approved scope, that needs to be tracked and fixed — with evidence an auditor can follow.
At any stage, findings, changes, or scope issues loop back into validation — every transition leaves an auditable trail.
Process
Policy → workflow translation
Worked with MRM Oversight, Model Owners, Controllers, and Internal Audit to translate enterprise MRM policy and supervisory expectations (SR 11-7-aligned) into concrete, screen-level workflows. Mapped the governance hierarchy — Enterprise MRM → MO → AO/TO → MC → MD/PR → LMU — into the platform's role model, permissions, and approval routing.
Model lifecycle architecture
Designed end-to-end flows for model creation, versioning, validation execution and scheduling, findings remediation, attestations, model associations, approved usages, and adjustments. Every state transition is logged, every role has a clear queue, and every artifact carries the evidence an examiner needs.
Segregation of duties by design
Embedded clear accountability into the UI itself — MD builds, PR independently reviews, MC controls the lifecycle, MO owns business risk, AO/TO own application and infrastructure, LMU applies outputs to decisions. The platform refuses to let one role do another's job, which is what auditors look for first.
DevJoy — AI training on top of MUSE
Designed DevJoy so model developers can train and iterate banking models without leaving governance behind. Training runs inherit the parent model's controls, assumptions, and approved-usage scope; versioning, validation schedules, and findings update automatically as work moves forward.
Audit & examination readiness
Made traceability the default, not a report. Every model surfaces its version history, validation status, open findings, attestations, associations, and usage map on one screen — so independent validation, internal audit, and regulatory reviews can be answered with a link instead of a binder.
Outcomes
Full design walkthrough
Auto-advancing prototype of every screen in the model lifecycle, in order — from registration intake through activation and reactivation. Pause, scrub, or step frame by frame.

































All screens
Registration intake
The Model Developer captures what the model is, how it's built, and who's accountable — AI/ML technique, NPI handling, owners, delegates, and the inputs/outputs that downstream apps depend on.



Submission & risk tiering
Registration completes, quick actions appear, and the model moves into MRM review. The MO suggests a Risk Tier; MRM determines the final one using the Risk Tiering Worksheet.







MRM review & multi-role approvals
Stage 2 in three parts: inputs and peer review, associations and assumptions, then MDP approval with the full stakeholder sign-off chain. Implementation docs are reviewed and the Lead Validator attests.







Activation
Once MRM approves, the MC accepts management status, confirms in-use and implementation dates, and activates the version against its approved usages — without disturbing existing downstream consumers.







Reactivation
A retired model comes back. Planning submission, owners and roles reconfirmed, associations and risk re-evaluated, then Stage 1 and Stage 2 MRM review re-run with new governance approvals before it's live again.








