Model Risk Management

The Model Risk Management (MRM) extension describes the models an organization relies on for decisions and regulatory reporting, and the records that keep them under control: governance, independent validation, ongoing monitoring and the mapping of regulatory obligations to controls and evidence. It complements the Risk Management domain, which records the risk a model poses as a risk profile.

Schema: model-risk-management.schema.json
Specification: JSON Schema Draft-07

Overview

What is Model Risk Management?

Model risk is the potential for adverse consequences from decisions based on incorrect or misused model outputs. Supervisory guidance such as SR 11-7 expects organizations to manage it across a model's life: sound development, independent validation, effective governance and ongoing monitoring. The MRM extension gives each of these a record:

• Model Profile — The model itself: what it is, what it is used for, who owns it and where it is in its lifecycle
• Model Governance — Roles, approval decisions, change events and policy exceptions
• Model Validation — Independent review: plan, activities, findings and remediation
• Model Monitoring — Key risk indicators, performance metrics, drift and alerts
• Regulatory Framework Mapping — Clause-level obligations linked to controls and evidence

Identifiers and Links

Every record has an identifier ending in ID: modelID for the model profile, and governanceID, validationID, monitoringID and frameworkMapID for the other records. Elements inside records are identified the same way (eventID, exceptionID, activityID, findingID, actionID).

Governance, validation and monitoring records each carry the modelID of the model they belong to. A regulatory framework mapping lists the models it covers in modelIDs; omit modelIDs when the mapping covers the model risk framework as a whole rather than particular models.

Relationship to the Risk Management Domain

A risk profile for model risk uses the Risk Management schema. Its risk category list has no separate model value, so model risk is recorded there as operational; the model itself is described by an MRM model profile.

Model Profile Attributes

The schema's root describes the model.

Attribute	Type	Description	Required
modelID	String	Unique identifier for the model, e.g. MODEL-ECL-IFRS9-001	✓
title	String	Model name	✓
description	String	Purpose and scope of the model	✓
modelType	String	Classification of the model, e.g. creditRisk/ECL_IFRS9	✓
useCategory	String	Primary use of the model, e.g. provisioning, pricing, capital, stressTesting
orgUnitTitle	String	Accountable organization unit
orgUnitID	String	ID of the organization unit named in orgUnitTitle
orgUnitRoles	Array[String]	Key roles, e.g. Model Owner, Independent Validator, Approver
modelOwner	String	Named owner of the model
regulatoryRelevance	Array[String]	Regulatory frameworks that apply, e.g. IFRS9, SR 11-7, CCAR
businessCriticality	String	Criticality tier, e.g. C1, C2, C3
status	Enum	Lifecycle state of the model (see Model Lifecycle)	✓
relatedInformationAssets	Array[String]	Key datasets the model uses
relatedInformationIDs	Array[String]	IDs of the information assets the model uses
supportsCapabilities	Array[String]	Capabilities the model supports
supportsCapabilityIDs	Array[String]	IDs of the capabilities the model supports
crossDomainRelationships	Array[Object]	Directional relationships from this model to entities in other domains: targetDomain, relationshipType and description (required), targetEntityID, metadata (see Cross-Domain Relationships)

Model Lifecycle (status)

A model's status is its lifecycle state (the schema's modelStatus definition):

Value	Description
inDevelopment	Being built or redeveloped; not yet submitted for validation
pendingValidation	Submitted and awaiting independent validation
underValidation	Independent validation in progress
approved	Validated and approved for use
conditionallyApproved	Approved for use subject to conditions or remediation
inUse	In production use for its approved purpose
underReview	In use, but under periodic or triggered review
suspended	Use temporarily stopped pending remediation or review
retired	Decommissioned and no longer used

Model Governance Elements

Model Governance (modelGovernance)

Attribute	Type	Description	Required
governanceID	String	Unique identifier for the governance record	✓
modelID	String	ID of the model this record belongs to	✓
roles	Object	People or bodies holding governance roles: owner, sponsor, independentValidator, approver, challenger
approval	Object	Approval decision: decision, date, conditions, approver
changeEvents	Array[Object]	Changes to the model and their approval (see below)
exceptions	Array[Object]	Exceptions granted against policy (see below)
documentationReferences	Array[Object]	Policies, approvals, reports or assessments used as evidence (see Documentation Reference)

Change Event (changeEvents)

Attribute	Type	Description	Required
eventID	String	Unique identifier for the change event	✓
type	String	Kind of change, e.g. material, nonMaterial
description	String	What changed	✓
effectiveDate	Date	When the change takes effect
approvedBy	String	Who approved the change
rollbackPlan	String	How the change would be reversed

Exception (exceptions)

Attribute	Type	Description	Required
exceptionID	String	Unique identifier for the exception	✓
rationale	String	Why the exception was granted	✓
expiry	Date	When the exception expires
compensatingControls	Array[String]	Controls compensating for the exception

Model Validation Elements

Model Validation (modelValidation)

Attribute	Type	Description	Required
validationID	String	Unique identifier for the validation	✓
modelID	String	ID of the model this record belongs to	✓
independence	Boolean	Whether the validation was performed independently of model development
plan	Object	Scope and methods: scope, methods (validation methods applied)
activities	Array[Object]	Validation activities (see below)
findings	Array[Object]	Validation findings (see below)
remediation	Array[Object]	Remediation actions (see below)
documentationReferences	Array[Object]	Policies, approvals, reports or assessments used as evidence

Validation Activity (activities)

Attribute	Type	Description	Required
activityID	String	Unique identifier for the activity	✓
category	Enum	Validation method the activity applies
date	Date	Date of the activity
tooling	String	Tools used
evidence	String	Evidence produced

Validation Finding (findings)

Attribute	Type	Description	Required
findingID	String	Unique identifier for the finding	✓
category	String	Kind of finding, e.g. calibration, dataQuality, documentation
severity	Enum	Severity of the finding (shared four-point rating)
description	String	Description of the finding	✓
evidenceRef	String	Reference to supporting evidence
dueDate	Date	When the finding must be addressed
owner	String	Who owns the finding

Remediation Action (remediation)

Attribute	Type	Description	Required
actionID	String	Unique identifier for the remediation action	✓
action	String	What will be done	✓
owner	String	Who is responsible
dueDate	Date	When it is due
status	Enum	Progress of the action (shared work status: proposed, planned, approved, inProgress, onHold, deferred, completed, cancelled)

Validation Method (methods)

Used by the plan's methods and by an activity's category (the schema's validationMethod definition).

Value	Description
conceptualSoundness	Review of model design, theory and choice of method
dataQuality	Review of the data used to develop and run the model
assumptions	Review of key assumptions and their justification
outcomesAnalysis	Comparison of model outputs with actual outcomes, such as backtesting
benchmarking	Comparison with alternative models or external estimates
implementationVerification	Verification that the model is implemented as designed

Finding Severity (severity)

Value	Description
low	Minor issue; address in the normal course of business
medium	Issue that should be remediated within an agreed timeframe
high	Significant weakness requiring prompt remediation
critical	Fundamental weakness; the model may not be fit for use until resolved

Model Monitoring Elements

Model Monitoring (modelMonitoring)

Attribute	Type	Description	Required
monitoringID	String	Unique identifier for the monitoring record	✓
modelID	String	ID of the model this record belongs to	✓
kri	Array[Object]	Key risk indicators (see below)
performanceMetrics	Array[Object]	Performance metrics such as calibration error, stability (PSI) and discrimination (AUC): name (required), currentValue, threshold
driftAssessment	Object	Data, concept and performance drift: dataDrift, conceptDrift, performanceDrift
alerts	Array[Object]	Alert conditions with responsible parties and required action: when (required), who, actionRequired
dependencies	Array[Object]	Dependencies on other domains: dependencyType (critical, important, supportive, optional), domainType and entityID (required), description

Key Risk Indicator (kri)

Attribute	Type	Description	Required
indicatorName	String	Name of the key risk indicator	✓
description	String	What the indicator measures
currentValue	Number	Current value
threshold	Number	Threshold that triggers action
trend	Enum	Direction of the indicator judged against its goal: improving, stable, declining, fluctuating, notTracked
monitoringFrequency	Enum	How often the indicator is measured (shared frequency list, e.g. daily, monthly, quarterly)

Drift Level (dataDrift)

Used by dataDrift, conceptDrift and performanceDrift (the schema's driftLevel definition).

Value	Description
noneObserved	No drift detected
low	Minor drift within tolerance
medium	Noticeable drift; investigate and monitor closely
high	Material drift; action required

Regulatory Framework Mapping Elements

Regulatory Framework Mapping (regulatoryFrameworkMapping)

Attribute	Type	Description	Required
frameworkMapID	String	Unique identifier for the regulatory mapping	✓
modelIDs	Array[String]	IDs of the models the mapping covers; omit when it maps the model risk framework as a whole
requirements	Array[Object]	Clause-level obligations with linked controls and evidence (see below)
documentationReferences	Array[Object]	Policies, approvals, reports or assessments used as evidence

Requirement (requirements)

Attribute	Type	Description	Required
framework	String	Regulatory framework, e.g. IFRS9, SR11-7	✓
reference	String	Clause or principle reference, e.g. IFRS9.5.5.17	✓
obligation	String	What the clause requires
appliesTo	Enum	Which part of model risk management the obligation applies to
controls	Array[String]	IDs of the controls meeting the obligation
evidence	Array[String]	Evidence that the obligation is met
status	Enum	Whether the obligation is met (shared compliance status: compliant, partiallyCompliant, nonCompliant, underReview, exempt, notApplicable)

Applies To (appliesTo)

The values follow the scope of SR 11-7.

Value	Description
model	The model's design, theory and methodology
data	Data used to develop and run the model
implementation	How the model is implemented in systems
use	How model outputs are used in decisions and reporting
governance	Policies, roles, approvals and oversight
validation	Independent validation of the model
monitoring	Ongoing performance monitoring
other	Any other aspect

Shared Elements

Documentation Reference (documentationReference)

Governance, validation and framework mapping records cite their evidence in documentationReferences.

Attribute	Type	Description	Required
documentName	String	Name of the document	✓
location	String	Where the document is held
type	String	Kind of document, e.g. policy, assessment, report
date	Date	Date of the document

Examples

The examples describe one model, an IFRS 9 expected credit loss model, and the records that govern it.

Example 1: Model Profile

{
  "modelID": "MODEL-ECL-IFRS9-001",
  "title": "IFRS 9 Wholesale ECL",
  "description": "Expected credit loss model for wholesale portfolios.",
  "modelType": "creditRisk/ECL_IFRS9",
  "useCategory": "provisioning",
  "orgUnitTitle": "Risk Analytics",
  "orgUnitRoles": [
    "Model Owner",
    "Independent Validator",
    "Approver"
  ],
  "modelOwner": "Head of Credit Modelling",
  "regulatoryRelevance": [
    "IFRS9",
    "SR 11-7"
  ],
  "businessCriticality": "C1",
  "status": "approved",
  "relatedInformationAssets": [
    "Loans_History",
    "Macroeconomic_Scenarios"
  ],
  "supportsCapabilities": [
    "Financial Reporting",
    "Credit Risk Management"
  ]
}

Example 2: Model Governance

{
  "governanceID": "GOV-IFRS9-001",
  "modelID": "MODEL-ECL-IFRS9-001",
  "roles": {
    "owner": "Head of Credit Modelling",
    "sponsor": "CFO",
    "independentValidator": "Model Validation Lead",
    "approver": "Model Risk Committee"
  },
  "approval": {
    "decision": "approved",
    "date": "2025-07-01",
    "conditions": "Quarterly monitoring"
  },
  "changeEvents": [
    {
      "eventID": "CHG-2025-09-15",
      "type": "material",
      "description": "Macroeconomic scenario specification update",
      "effectiveDate": "2025-10-01",
      "approvedBy": "Model Risk Committee",
      "rollbackPlan": "Revert to v3.1 scenario set"
    }
  ],
  "exceptions": [
    {
      "exceptionID": "EXC-2025-01",
      "rationale": "Temporary data quality waiver for small segment",
      "expiry": "2025-12-31",
      "compensatingControls": [
        "Manual overlay ceiling = 20 bps"
      ]
    }
  ],
  "documentationReferences": [
    {
      "documentName": "MRM Policy",
      "location": "POL/MRM/2025-01",
      "type": "policy",
      "date": "2025-03-31"
    }
  ]
}

Example 3: Model Validation

{
  "validationID": "VAL-IFRS9-2025Q3",
  "modelID": "MODEL-ECL-IFRS9-001",
  "independence": true,
  "plan": {
    "scope": "Wholesale ECL v3.2",
    "methods": [
      "conceptualSoundness",
      "outcomesAnalysis",
      "benchmarking",
      "implementationVerification"
    ]
  },
  "activities": [
    {
      "activityID": "ACT-001",
      "category": "outcomesAnalysis",
      "date": "2025-08-12",
      "tooling": "backtesting-suite"
    }
  ],
  "findings": [
    {
      "findingID": "FND-007",
      "category": "calibration",
      "severity": "high",
      "description": "Positive bias vs. realised losses in SICR segment B",
      "evidenceRef": "BACKTEST-2025Q2",
      "dueDate": "2025-10-15",
      "owner": "Model Owner"
    }
  ],
  "remediation": [
    {
      "actionID": "REM-003",
      "action": "Recalibrate segment B PD curve",
      "owner": "Risk Analytics",
      "dueDate": "2025-10-10",
      "status": "inProgress"
    }
  ],
  "documentationReferences": [
    {
      "documentName": "Independent Validation Report 2025Q3",
      "location": "RISK-RPT-2025-0930",
      "type": "assessment",
      "date": "2025-09-30"
    }
  ]
}

Example 4: Model Monitoring

{
  "monitoringID": "MON-IFRS9-001",
  "modelID": "MODEL-ECL-IFRS9-001",
  "kri": [
    {
      "indicatorName": "ECL backtest error (MAPE)",
      "description": "Absolute % error vs realised losses",
      "currentValue": 0.031,
      "threshold": 0.05,
      "trend": "stable",
      "monitoringFrequency": "monthly"
    }
  ],
  "performanceMetrics": [
    {
      "name": "stabilityPSI",
      "currentValue": 0.07,
      "threshold": 0.1
    }
  ],
  "driftAssessment": {
    "dataDrift": "low",
    "conceptDrift": "noneObserved",
    "performanceDrift": "low"
  },
  "alerts": [
    {
      "when": "MAPE > 0.05 for 2 months",
      "who": [
        "Model Owner",
        "Independent Validator"
      ],
      "actionRequired": "Root-cause analysis and corrective plan"
    }
  ],
  "dependencies": [
    {
      "dependencyType": "critical",
      "domainType": "information",
      "entityID": "INFO:Loans_History"
    }
  ]
}

Example 5: Regulatory Framework Mapping

The mapping covers one model, so it lists it in modelIDs. The second requirement (SR 11-7 Principle 1) applies to governance and has no obligation text.

{
  "frameworkMapID": "REGMAP-IFRS9-001",
  "modelIDs": [
    "MODEL-ECL-IFRS9-001"
  ],
  "requirements": [
    {
      "framework": "IFRS9",
      "reference": "IFRS9.5.5.17",
      "obligation": "Incorporate unbiased, probability-weighted forward-looking information.",
      "appliesTo": "model",
      "controls": [
        "CTRL-SCENARIO-GOV-01",
        "CTRL-ASSUMPTIONS-LOG-03"
      ],
      "evidence": [
        "Scenario Pack 2025Q3",
        "Model Document v3.2"
      ],
      "status": "compliant"
    },
    {
      "framework": "SR11-7",
      "reference": "SR11-7.Principle1",
      "appliesTo": "governance",
      "controls": [
        "CTRL-SOD-DEV-VAL-02"
      ],
      "evidence": [
        "MRM Policy 2025",
        "Committee Minutes 2025-07-01"
      ],
      "status": "compliant"
    }
  ],
  "documentationReferences": [
    {
      "documentName": "MRM Policy",
      "location": "POL/MRM/2025-01",
      "type": "policy",
      "date": "2025-03-31"
    }
  ]
}

Implementation Guidelines

Model Risk Management Best Practices

1. Keep a complete model inventory — Record every model in use as a model profile with a modelID, owner and businessCriticality
2. Link every record to its model — Governance, validation and monitoring records carry the model's modelID
3. Validate independently — Record independence and the methods applied; track findings to remediation
4. Monitor continuously — Set KRI thresholds and alerts, and assess data, concept and performance drift
5. Map obligations to evidence — Link each regulatory clause to the controls and evidence that meet it, and record its compliance status
6. Keep the lifecycle current — Update the model's status as it moves through validation, use, review and retirement

For Data Engineers

Model monitoring records map naturally to ML observability tooling: KRIs and performance metrics to monitored metrics, drift levels to drift detectors, and alerts to alerting rules. A model's relatedInformationIDs link it to the Information domain records that describe its training and scoring data, supporting lineage from data to model to decision.

Schema Reference

• Repository: Triodian/Triodian_Metamodel
• Schema: model-risk-management.schema.json
• Specification: JSON Schema Draft-07
• License: Apache License 2.0

Related Documentation

• Risk Management Domain — Risk profiles, including model risk
• Information Domain — Data assets models use
• Cross-Domain Relationships — Relationship types for crossDomainRelationships