Skip to content

FRM Exam Part II · Supervisory Guidance on Model Risk Management

Model Development, Implementation and Use under SR 11-7

Updated 11 October 2026 · Fact-checked

Under SR 11-7, sound model development means a clear purpose, theory and data that fit that purpose, testing of accuracy and robustness, documented assumptions and limitations, and controlled implementation and use. Exam questions ask you to spot which of these practices is missing or weak and name the fix.

Understand Model Development, Implementation and Use

A model is a quantitative method that turns input assumptions into estimates. Model risk is the chance of loss or poor decisions because a model is wrong or misused. SR 11-7 splits this risk into two sources: fundamental errors in the model itself, and incorrect or inappropriate use of a model that may be sound.

The guidance treats the lifecycle in three parts: development and implementation, validation, and governance. This page covers the first part. It matters because validators and managers can only challenge what developers have made clear and testable.

Good development starts with a statement of purpose. The developer says what the model is for, who will use it and what decisions rely on it. Design choices then follow: the theory and method must be supported by research or published evidence, and the data must be relevant to the portfolio. Data must be checked for quality, and proxy data must be shown to be a reasonable stand-in. Where judgement replaces data, it must be explained.

Testing comes next. Developers check accuracy, robustness and stability, and run sensitivity analysis and stress tests of inputs. They check outcomes analysis where possible, such as back-testing or comparison with benchmarks. They test the model for the way it will be used, not only in the abstract. Documented testing covers the model's assumptions and limitations, so users know where results should not be trusted.

Implementation must be controlled. The code or system must match the design, so systems integration is tested and checked against the developer's version. Use must match purpose. When a model is used for a new product, new market or by new staff, it needs fresh review. Where a model has known weaknesses, users apply conservative adjustments or overlays and monitor them. Documentation must be detailed enough for an unfamiliar party to understand how the model works and to replicate it.

Key formulas to remember

Sources of model risk (SR 11-7)
Model risk = fundamental errors in the model + incorrect or inappropriate use
A sound model used outside its intended purpose still creates model risk.
Core development elements
Purpose → Design, theory and data → Testing → Implementation → Use and monitoring → Documentation
Use this as a checklist to find the missing step in a case question.
Developmental testing set
Accuracy, robustness and stability; sensitivity and stress tests; outcomes analysis and benchmarking
Testing must cover the range of conditions and the actual intended use.
Documentation standard
Detailed enough that a knowledgeable third party could understand and replicate the model
It should cover purpose, theory, data, assumptions, limitations, testing and controls.

How to solve Model Development, Implementation and Use questions

Use this approach for any question on model development, implementation and use.

  1. 1Identify the lifecycle stage in the case: design, data, testing, implementation, use or documentation.
  2. 2Restate the model's purpose and check whether the case uses it for that purpose.
  3. 3Check theory and data: is the method supported, is the data relevant and clean, and are proxies justified?
  4. 4Check testing: are accuracy, robustness, sensitivity, stress and outcomes analysis all present for the actual use?
  5. 5Check assumptions and limitations: are they stated, and are compensating controls or overlays in place?
  6. 6Check implementation: does the system match the design, and was integration tested?
  7. 7Check documentation and change control, then pick the option that closes the specific gap.

Quickest way: Purpose-Data-Test-Use-Document scan

When to use it: Use it when four options all sound like good practice and time is short.

  1. Find the single weakness in the stem: wrong purpose, poor data, thin testing, implementation gap or missing documentation.
  2. Reject options that add controls elsewhere.
  3. Prefer the option that directly addresses that weakness.
  4. Reject absolute wording such as always, never or eliminates model risk.
  5. Choose the option aligned with effective challenge and independent understanding.

Common mistakes in Model Development, Implementation and Use

  • Thinking model risk comes only from coding or math errors.

    Candidates focus on the model itself.

    Fix: Remember the two sources: fundamental errors and incorrect or inappropriate use.

  • Treating a good back-test as proof the model is sound.

    Outcomes analysis feels decisive.

    Fix: Back-testing is one test. Robustness, sensitivity, assumption checks and benchmarking are also needed.

  • Using a model on a new product because it worked on the old one.

    Candidates assume validity carries over.

    Fix: A new use needs review against the original purpose and limitations.

  • Seeing documentation as an administrative extra.

    It looks less technical than testing.

    Fix: Documentation enables validation, challenge, continuity and audit. Weak documentation is a control weakness.

  • Assuming proxy data is acceptable without evidence.

    Real data is often scarce.

    Fix: The developer must show the proxy is relevant and explain any adjustments.

  • Believing limitations can be left out to avoid worrying users.

    Candidates confuse confidence with quality.

    Fix: State limitations clearly so users apply conservatism and avoid misuse.

Worked examples

Example 1

A bank builds a retail credit loss model using five years of data that include no recession. The documentation states that the model has been back-tested with good results and does not mention the data period. Which is the main development weakness, and what is the best remedy?
A) Excessive complexity, so use a simpler model
B) Data not representative of stress conditions, so add stress testing, document the limitation and consider conservative overlays
C) Back-testing was done, so no change is needed
D) Implementation error, so recode the model

Show the solution
  1. The stem points to data covering a benign period only.
  2. Good back-test results in a benign period say little about behaviour in stress.
  3. SR 11-7 expects data relevance, tested robustness and stated limitations.
  4. Option B addresses data, testing and documentation together. Option A does not address the gap. Option C overstates back-testing. Option D has no evidence.

Answer: B

Example 2

A treasury team adopts an interest rate risk model built for fixed-rate mortgages to measure risk on a new portfolio of floating-rate loans, relying on the original validation. Which SR 11-7 principle is most directly breached?
A) Model documentation must contain code listings
B) Models must always use market data
C) Use must match the model's intended purpose, and a new use requires review
D) Models must be replaced every year

Show the solution
  1. The model is sound for its original purpose, but the new portfolio differs.
  2. SR 11-7 says incorrect or inappropriate use is a source of model risk.
  3. Prior validation was for a different use, so it does not cover the new one.
  4. Options A, B and D are not SR 11-7 requirements.

Answer: C

Exam tips

  • Questions are case-based. Locate the lifecycle stage first, then match the remedy.
  • Watch for stems where testing looks good but data or use is the real flaw.
  • Expect absolute wording traps: eliminate, guarantee, always.
  • Remember that documentation should allow a knowledgeable third party to understand and replicate the model.
  • Link limitations to controls such as overlays, limits and monitoring.

Practice questions from Supervisory Guidance on Model Risk Management

Model Development, Implementation and Use in other exams

The same ground in other exams, if you are preparing for more than one or want another angle on it.

Model Development, Implementation and Use: frequently asked questions

What does SR 11-7 say about model development?

It expects a clear purpose, sound theory and relevant data, rigorous testing, documented assumptions and limitations, and careful implementation. The aim is a model that is fit for its use and can be understood and challenged.

How should a model be documented?

Documentation should be detailed enough for a knowledgeable third party to understand how the model works and replicate it. It should cover purpose, theory, data, assumptions, limitations, testing results and controls.

Why must assumptions and limitations be stated?

Users need to know where the model may fail so they do not rely on it beyond its range. Stated limitations support conservative adjustments, monitoring and proper challenge.

Is development testing the same as validation?

No. Developers test their own model during build and implementation. Validation is a separate, independent review that provides effective challenge.