MUSE — Model Risk Management at Fannie Mae
One model lifecycle. Seven accountable roles. One audit trail.
Overview
The case in one minute
faster MUSE model-validation cycle
Claims & Recovery approval turnaround (separate workstream)
legacy applications consolidated into one system of record
- Role
- Lead UX Designer (employment title). Sole product designer for MUSE.
- Team
- Cross-functional team of ~25 — engineering, product management, quantitative model developers, validators and model-risk governance. No other product designer on MUSE.
- Duration
- Jul 2023 — Aug 2026 · 24+ months
- Scope
- Product design across model registration, validation, governance, activation, revalidation and reporting for MUSE, plus DevJoy, its AI training surface.
- Primary users
- Enterprise MRM, Model Owners, Model Developers, Peer Reviewers, Model Controllers, Application Owners and Lead Model Users — plus Internal Audit as a reviewing audience.
- Constraints
- SR 11-7-aligned model-risk policy, segregation of duties enforced in-product, three legacy applications to consolidate, and a regulated internal environment where every state change must be provable.
Attribution
I owned design direction and the functional definition of the platform. Delivery was a team effort: engineering built it, product managed scope, and model-risk governance approved every policy decision — I recommended, they approved. Metrics were instrumented by product, finance and operations, not by me.
Regulated internal platform. Every screen shown is a reconstruction — no production UI, customer data or internal system detail. Reconstruction is a visual disclosure only; it does not verify the outcomes above.
Situation and stakes
No one could prove a model was reviewed, current and approved.
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 is the system where Fannie Mae's models are created, governed and managed. A model, here, is analytics, machine-learning structure and AI baked together so it can assist in producing reports built to federal guidelines — reports consumed by insurers, auditors and government reviewers. The supporting tooling had sprawled into fragmented internal apps, each owned by a different team and used by a different persona — model owners, lead model users, auditors and governance specialists — with no shared design language, navigation or data model between them.
The problem, in 45 seconds: hundreds of models, three legacy applications, five roles, and no single place to prove anything. Everything shown is a stand-in — no real screens or data.
Why this system was hard
How the system works — Feeder and MUSE
The platform has two parts. The Feeder is the intake layer: it gathers information from many local sources — field reporters, data providers, institutional partners and public submissions — and channels it inward. MUSE is the second part: the layer where models are created, governed and managed. Each model combines analytics, machine-learning structure and AI so it can assist in producing reports built to federal guidelines. Those reports serve many consumers — insurers, auditors and government reviewers — which is why every model must be provably sound, independently validated and used only within its approved scope. A model's lifecycle starts when someone registers it, runs through independent validation and activation, and must be revalidated regularly until retirement. 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.
Roles
Lifecycle
- Register
- Validate
- Approve
- Activate
- Revalidate
- Retire / Reactivate
Surfaces
Team
Sole product designer for MUSE. Cross-functional: ~25 (eng, PM, MRM officers, audit partners).
Stakeholders
VP Model Risk Management, Chief Model Risk Officer, Head of Internal Audit, Director of TechOps, regulator-facing review committee.
Decision authority
I decided design direction and the functional definition of the platform. Model-policy approval remained with risk governance — I recommended, they approved.
Three consequential decisions
What I decided, and what it cost.
- 01
Reframed which of five validation gates genuinely had to block, instead of speeding up a process that did not need to be serial.
Stopped a proposed 'super-admin' role — would have collapsed segregation of duties and broken SR 11-7 traceability. Re-routed work into role-aware queues instead.
- 02
Made evidence the default object of the interface — every stage shows what was reviewed, by whom and when, rather than a status word.
Pushed back on a 'wizard-only' registration pattern; designed a stateful, resumable flow because real models take weeks to register across teams.
- 03
Designed a separate AI-assisted approval workflow for Claims and Recovery rather than bending the MUSE validation lifecycle to fit it.
Aligned MRM, Audit and Engineering on a single status taxonomy — eliminated 3 conflicting lifecycle vocabularies that had been fighting in tickets for years.
How the work was run
- 01
Translated SR 11-7-aligned MRM policy into concrete, screen-level workflows with MRM Oversight, Model Owners, Controllers and Internal Audit.
- 02
Designed end-to-end flows for model creation, versioning, validation execution and scheduling, findings remediation, attestations and approved usages.
- 03
Embedded segregation of duties into the UI — the platform refuses to let one role do another's job, which is what auditors look for first.
- 04
Designed DevJoy so developers can train and iterate banking models without leaving governance behind — versioning, validation schedules and findings update automatically.
AI and human control
How DevJoy handles the hard parts of putting ML behind a regulated governance surface.
Confidence & provenance on every model output
- Risk / failure mode
- Model owners and auditors need to know not just what a model said, but how sure it was and what data shaped that answer — without drowning in telemetry.
- Design decision
- Every prediction surfaces a confidence band, the model version that produced it, and a one-click jump to the validation run, data lineage and approved-usage scope it was sanctioned under.
- Human control
- A reader can always trace an output back to the version, validation run and approved usage that sanctioned it — and can reject an output that falls outside that scope.
- Trade-off
- Adds vertical density on the result card; we earned it back by collapsing four legacy 'evidence' tabs into one inline strip.
- Result
- Provenance stopped being a request to another team and became a link on the object itself.
Human-in-the-loop validation queues
- Risk / failure mode
- Independent validators were being asked to rubber-stamp AI-flagged findings. That breaks the independence regulators require.
- Design decision
- Built a dual-track queue: AI proposes a finding severity and remediation, but the validator must independently classify before they can see the AI's suggestion. Disagreements are logged as governance evidence.
- Human control
- The validator classifies first and can override the model outright; the Lead Validator attestation is the human signature the record depends on.
- Trade-off
- Slower throughput per validator, but every disagreement became a training signal — and audit defensibility went from 'argue about it' to 'point at the log'.
- Result
- Every disagreement between validator and model became logged governance evidence rather than an unrecorded judgement call.
Hallucination guardrails on AI training flows
- Risk / failure mode
- DevJoy lets developers train new banking models. A hallucinated assumption baked into a training run can silently invalidate downstream approvals.
- Design decision
- Training runs inherit the parent model's approved assumptions as locked guardrails. Any AI-suggested change to assumptions, inputs or scope routes to MO + PR for explicit re-attestation before the run continues.
- Human control
- The run stops until a named Model Owner and Peer Reviewer re-attest; escalation is a routed decision with an owner, not a warning banner.
- Trade-off
- Adds friction the first time a developer wants to deviate; the friction is exactly the control auditors asked for.
- Result
- A model cannot drift outside its approved assumptions without a named human accepting that change on the record.
Shipped experience
One lifecycle, one audit trail, seven accountable roles.
MUSE consolidated registration, validation, activation, revalidation and retirement into one workflow with role-aware queues, attestation chains and an audit trail every regulator can follow.
How the platform works, in 90 seconds. Screens are rebuilt from scratch — nothing here is real client UI or data.
Screens are grouped by the decision they demonstrate. Every image expands. All screens are reconstructions — no production UI or data.
Act 01Registration intake3 screens▾
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.
Act 02Submission & risk tiering7 screens▾
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.
Act 03MRM review & multi-role approvals7 screens▾
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.
Act 04Activation7 screens▾
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.
Act 05Reactivation9 screens▾
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.
Outcomes and provenance
What changed, and how it was measured.
- 01
Enterprise system of record adopted across MRM, audit and business stakeholders.
- 02
MUSE model-validation lifecycle: cycle time reduced ~60% (internal operational reporting, rounded).
- 03
AI approval workflow for Claims and Recovery — a separate workstream: approval turnaround moved from roughly two months to two to four days.
A separate recoveries workstream that ran in parallel collapsed from one week to a few hours. Kept distinct from MUSE lifecycle metrics to preserve a clean audit narrative.
Metric provenance · Two separate workstreams, two separate baselines. (1) MUSE model-validation lifecycle: baseline is the legacy five-stage validation process; window is 6 months after general availability against the same period the prior year; ~60% faster, rounded. (2) AI approval workflow for Claims and Recovery: a distinct project — approval turnaround moved from roughly two months to two to four days after launch. Source for both is confidential internal operational reporting; I designed the workflows, product, finance and operations owned instrumentation.
Reflection
What I would carry forward
The hardest work here was not the interface. It was deciding which parts of a governance process genuinely had to block, and defending that answer to people whose job is to say no. Reframing the five validation gates saved more time than any screen I drew.
Making evidence the default object of the interface — what was reviewed, by whom, when — turned out to be the pattern that generalised. It is what let audit stop arguing and start pointing at a log, and it is the first thing I would build again in any regulated AI product.
I would also keep the discipline of refusing to bend one workflow to fit another. Designing the Claims and Recovery approval flow separately, rather than forcing it through the MUSE validation lifecycle, is why both stayed legible.