Model Risk Management Guide

This guide is written for model risk managers, Chief Risk Officers, internal audit teams, and examination-readiness staff responsible for AI governance under OCC Bulletin 2011-12 (SR 11-7) and Federal Reserve SR 11-7. It describes how to use the Arbitex Model Registry to operate a compliant, examination-ready model risk management program for AI models.

If you are an engineer looking for API endpoints, request/response schemas, and the validation status state machine, see the Model Registry technical reference instead.

---

What Arbitex provides

Arbitex is an AI Gateway — a control plane that intermediates all AI model traffic between your organization’s users and AI providers. In the context of model risk management, the platform provides:

• A centralized model inventory that captures every AI model your organization accesses, whether registered manually or discovered automatically from the audit log.
• OCC SR 11-7 aligned risk tiers — a five-value classification scheme (critical, high, medium, low, unclassified) directly mapped to SR 11-7 materiality concepts.
• A structured validation lifecycle with enforced allowed transitions and an immutable approval log written at every status change.
• Policy Engine integration that enforces governance controls at runtime — blocking unvalidated models, prompting users accessing high-risk models, and routing requests to approved alternatives.
• Exportable inventory and audit trail — CSV and JSON exports for examiner submissions, with usage statistics (usage_30d, usage_90d, last_used_at) to demonstrate ongoing monitoring.

Arbitex does not replace the human validation process required under SR 11-7. Independent model validation — review by qualified validators who are independent of model development — remains an organizational responsibility. Arbitex provides the governance infrastructure: the inventory, the audit trail, the workflow, and the runtime enforcement that examiners look for.

---

SR 11-7 framework overview

OCC Bulletin 2011-12 (“Supervisory Guidance on Model Risk Management”), commonly referenced as SR 11-7, establishes supervisory expectations for how financial institutions manage the risks posed by quantitative models. The Federal Reserve issued the same guidance simultaneously as SR 11-7. The guidance applies to all models used in business decisions, regardless of whether the model was developed internally or acquired from a vendor.

SR 11-7 organizes model risk management around five pillars:

1. Model inventory and documentation

Institutions must maintain a comprehensive inventory of all models in use. The inventory should capture the model’s purpose, owner, development history, inputs, outputs, assumptions, and limitations. For AI models specifically, this extends to the provider, model version, and approved use cases.

Arbitex coverage: The Model Registry is the AI model inventory. Each entry captures model ID, provider, risk tier, validation status, owner, description, approved use cases, and restrictions. Auto-discovery ensures newly appearing models are surfaced within 24 hours.

2. Risk classification by materiality

SR 11-7 requires institutions to classify models according to their potential impact. Higher-materiality models require more rigorous validation and oversight. The guidance does not prescribe specific tier labels, but expects a tiered approach that allocates validation resources proportionally.

Arbitex coverage: The five-tier RiskTier enum provides the classification scaffold. See Risk Tier Classification below.

3. Independent model validation

SR 11-7 requires validation to be performed by staff independent of the model development function. Validation must be conceptually sound, the data used for development must be checked for appropriateness, and the model’s performance must be evaluated against outcomes.

Arbitex coverage: The under_review and approved/conditional validation statuses track where each model is in the validation process. The immutable approval log records who approved the transition and the stated rationale. Conditional approvals use the restrictions field to constrain permitted use.

4. Ongoing monitoring and outcomes analysis

SR 11-7 expects institutions to continuously monitor model performance after deployment. This includes tracking whether models are being used as approved, reviewing outcomes against predictions, and identifying model drift or degradation.

Arbitex coverage: The audit log records every AI model request. Inventory exports include usage_30d, usage_90d, and last_used_at to surface usage patterns. Policy Engine rules can detect and flag requests that fall outside a model’s approved use cases.

5. Governance and controls

SR 11-7 requires senior management oversight, clear policies, defined roles and responsibilities, and an internal audit function that independently tests model risk management effectiveness.

Arbitex coverage: The platform provides the governance infrastructure — inventory, audit trail, policy enforcement, and export capabilities. Organizational governance (policies, senior management oversight, audit program) remains an institutional responsibility.

---

Risk tier classification

Risk tier assignment is the first substantive decision in the model governance workflow. The tier determines the validation rigor required, the monitoring frequency, and which Policy Engine rules apply at runtime.

Tier definitions

Tier value	SR 11-7 materiality	Typical AI use cases
critical	Tier 1 — Highest risk, strictest controls	Credit scoring, fraud detection, algorithmic trading, regulatory capital models, stress testing
high	Tier 2 — Enhanced controls, full validation lifecycle	Customer segmentation, AML screening, risk appetite models, underwriting assistance
medium	Tier 3 — Standard controls and validation requirements	Internal analytics, process automation, summarization in regulated workflows, compliance document review
low	Tier 4 — Lightest review cadence	Internal productivity tooling, sandboxed R&D, non-consequential document drafting
unclassified	Not yet assessed	Default for all auto-discovered models and newly registered models before triage

Tier assignment decision process

Use the following checklist when reviewing an unclassified model. Work top to bottom — the first matching criterion determines the tier.

Assign critical if the model:

• Produces output that directly drives a credit decision, loan approval, or denial
• Contributes to fraud scoring or fraud action decisions on customer accounts
• Is used in algorithmic trading execution or position sizing
• Informs regulatory capital calculations or stress test submissions
• Outputs are submitted directly to a regulator or used in regulatory filings

Assign high if the model:

• Influences but does not solely determine credit or fraud outcomes (human-in-the-loop)
• Supports AML screening, alert generation, or suspicious activity identification
• Is used in customer segmentation that affects pricing, product availability, or service access
• Informs risk appetite decisions that influence business limits or strategy

Assign medium if the model:

• Produces output reviewed by a regulated employee before any consequential action
• Assists with compliance document drafting, review, or summarization in a regulated context
• Is used in internal analytics that inform (but do not drive) business decisions
• Automates internal processes in a regulated business line

Assign low if the model:

• Is used solely for internal productivity with no downstream regulated output
• Operates in a sandboxed R&D environment not connected to production systems
• Produces output that is reviewed and modified by a human before any use
• Has no plausible pathway to influence a regulated decision or customer outcome

If uncertain between tiers: Assign the higher tier. Tier can be revised downward as part of the validation process if the validator determines the lower tier is appropriate.

---

Validation lifecycle workflow

The following seven-step workflow describes the operational process for moving an AI model from discovery through active production use, and eventually to retirement. The platform enforces the allowed state transitions — invalid transitions are rejected with HTTP 422.

State machine

stateDiagram-v2
    [*] --> unclassified : registered / discovered
    unclassified --> under_review : submit for review
    under_review --> approved : validation passed
    under_review --> conditional : approved with constraints
    under_review --> unclassified : returned (insufficient info)
    approved --> conditional : constraints applied
    approved --> deprecated : model sunset
    conditional --> approved : constraints lifted
    conditional --> deprecated : model sunset
    deprecated --> under_review : reactivation

Allowed transitions

From status	Allowed next statuses
unclassified	under_review
under_review	approved, conditional, unclassified
approved	deprecated, conditional
conditional	approved, deprecated
deprecated	under_review

Step 1: Discovery

Trigger: Auto-discovery runs on a 24-hour schedule and can be triggered on-demand.

Auto-discovery scans the audit log for AI request events and creates new registry entries for any (model_id, provider) pair not already present. Newly discovered entries are assigned risk_tier: unclassified and validation_status: unclassified.

On-demand discovery:

POST /api/v1/admin/models/discover

No request body. Returns a count of newly created entries and their full registry records.

Manual registration is also available for models not yet accessed through the platform:

POST /api/v1/admin/models

In either case, new entries land in unclassified status and require triage.

Checklist:

• Run on-demand discovery after deploying new AI integrations
• Review the Model Registry after each automatic discovery cycle
• Confirm no new entries were created without a corresponding project or use case

Step 2: Triage

Trigger: Unclassified models appear in the registry.

Review each unclassified entry and assign a risk tier using the decision checklist in Risk Tier Classification. Update the registry entry to set:

• risk_tier — the assessed tier
• owner — the team or individual accountable for this model
• description — the model’s purpose and scope within your organization
• approved_use_cases — the list of contexts in which use is sanctioned

PUT /api/v1/admin/models/{id}

Checklist:

• Every unclassified model has been reviewed by an owner
• Risk tier is documented with a rationale
• Owner is assigned (not left null)
• Approved use cases are populated
• Models that cannot be attributed to an approved project are flagged for investigation

Step 3: Submit for review

Trigger: Triage complete — the model is ready for independent validation.

Transition the model to under_review using the Status Transition API. The reason field is required and written to the immutable approval log.

POST /api/v1/admin/models/{entry_id}/status

{
  "status": "under_review",
  "reason": "Triage complete. Risk tier assessed as high. Owner: ai-risk-team. Submitting for independent validation per SR 11-7 requirements."
}

Checklist:

• Triage fields (owner, description, approved_use_cases) are complete before submission
• Reason text documents the triage decision basis
• Model validator has been notified

Step 4: Validation

Trigger: Model status is under_review.

This step is performed by the model risk team (validators). Validation scope is determined by the risk tier:

Tier	Validation requirements
critical	Full SR 11-7 validation: conceptual soundness review, data quality assessment, performance benchmarking, sensitivity analysis, outcomes analysis plan, and documentation of assumptions and limitations
high	Conceptual soundness review, data quality assessment, performance evaluation, documentation review
medium	Documentation review, use case appropriateness review, performance assessment
low	Lightweight review: use case appropriateness, owner attestation

During validation, the model remains in under_review status. No production policy rules should grant access to models in this status until the review is complete.

Checklist:

• Validator is independent of model development and procurement
• Validation scope is appropriate to the risk tier
• Validation findings are documented
• Approved use cases list has been reviewed and confirmed or amended

Step 5: Approval or conditional approval

Trigger: Validation is complete.

The validator records the outcome using the Status Transition API:

Unconditional approval:

{
  "status": "approved",
  "reason": "Full SR 11-7 validation complete. Conceptual soundness confirmed. No material deficiencies identified. Approved for production use in [use case]."
}

Conditional approval (approved with constraints):

{
  "status": "conditional",
  "reason": "Approved with use-case restrictions. Model performs acceptably for [use case A] but exhibits drift for [use case B]. Restrictions applied."
}

When transitioning to conditional, update the restrictions JSONB field to document the specific constraints:

PUT /api/v1/admin/models/{id}

{
  "restrictions": {
    "prohibited_use_cases": ["customer_lending_decisions"],
    "required_human_review": true,
    "review_note": "Outputs must be reviewed by a licensed analyst before any customer action"
  }
}

Return to unclassified if the submission was insufficient:

{
  "status": "unclassified",
  "reason": "Submission returned. Insufficient use case documentation. Owner must re-document approved use cases and resubmit."
}

Checklist:

• Transition reason documents the validation outcome
• Conditional approvals have restrictions populated in the registry entry
• Policy Engine rules have been updated to reflect the new status
• Model owner has been notified of the outcome

Step 6: Ongoing monitoring

Trigger: Model is approved or conditional — in production use.

Review usage statistics from inventory exports to verify:

• The model is being used at expected volumes
• Usage patterns are consistent with approved use cases
• No anomalous access patterns (e.g., unexpected user groups, usage spikes)

Revalidation is required on the cadence defined by tier. See Ongoing Monitoring Program for the full schedule and procedures.

Checklist:

• Quarterly review of usage statistics for critical models
• Semi-annual review for high models
• Annual review for medium models
• Revalidation submitted before the period deadline
• Anomalous usage patterns investigated and documented

Step 7: Deprecation

Trigger: Model is being retired or replaced.

Transition the model to deprecated when the model is no longer approved for use.

{
  "status": "deprecated",
  "reason": "Model retired. Replaced by [new model]. All integrations have been updated to the replacement model."
}

Immediately after deprecation, update your Policy Engine rules to block requests to the deprecated model. A CANCEL rule targeting deprecated models is the recommended control.

If a deprecated model needs to be reactivated (e.g., a replacement fails and you need to roll back), transition to under_review to initiate a revalidation cycle before restoring production access.

Checklist:

• Policy Engine updated to block deprecated model
• Model owner and dependent teams notified
• Replacement model (if any) is approved before deprecating the predecessor

---

Policy Engine integration

Validation status and risk tier connect to runtime enforcement through the Policy Engine. Controls operate at request time — before the request reaches the AI provider.

Blocking unvalidated models

The most important control is preventing unvalidated models (unclassified, under_review) from being accessed in production. Use a CANCEL rule to enforce this.

{
  "name": "Block unvalidated models — all users",
  "conditions": {
    "model_risk_tier": ["unclassified"]
  },
  "action": "CANCEL"
}

To additionally block access to models currently under review, ensure your policy rules do not positively grant access to under_review models for general user groups.

Blocking deprecated models

{
  "name": "Block deprecated models",
  "conditions": {
    "model_risk_tier": ["critical", "high", "medium", "low"]
  },
  "action": "CANCEL"
}

Note: The model_risk_tier condition matches on the registry’s risk_tier field, not validation_status. To enforce controls based on validation status, combine model_risk_tier conditions with group conditions to restrict access to only groups that have explicit authorization for validated models.

Prompting users for high-risk models

For high and critical tier models, require user acknowledgment before each session to reinforce SR 11-7 governance controls and create an accountable record of use.

{
  "name": "Governance disclosure — high-risk models",
  "conditions": {
    "model_risk_tier": ["high", "critical"]
  },
  "action": "PROMPT",
  "prompt_text": "You are accessing a Tier 1/2 AI model subject to your organization's model risk management policy. Use is restricted to approved use cases. Proceed only if your use is consistent with your approved use case documentation."
}

Routing to approved alternatives

For use cases where a critical or deprecated model has been blocked, route users to an approved lower-tier alternative rather than returning an error.

{
  "name": "Route critical-tier requests to approved alternative",
  "conditions": {
    "model_risk_tier": ["critical"]
  },
  "action": "ROUTE_TO",
  "route_target": "approved-medium-tier-model"
}

Restricting access to validated-only groups

Combine model_risk_tier conditions with group membership to allow the model risk team to access models under review while blocking general users.

{
  "name": "Allow model-risk-team access to under-review models",
  "conditions": {
    "group": ["model-risk-team"],
    "model_risk_tier": ["critical", "high", "medium", "low"]
  },
  "action": "ALLOW"
}

Position this rule before the blocking rules in your policy chain so it evaluates first for model risk team members.

For detailed rule combining logic, see Policy Engine Deep Dive.

---

Examination preparation

When preparing for an OCC, Fed, or internal audit examination focused on AI model risk management, the following procedures demonstrate SR 11-7 compliance using Arbitex.

Model inventory export

Provide examiners with a complete model inventory in their preferred format.

GET /api/v1/admin/model-inventory-export?format=csv
GET /api/v1/admin/model-inventory-export?format=json

The export includes:

Field	Examiner relevance
model_id / provider	Unique model identification
display_name	Human-readable label
risk_tier	SR 11-7 materiality classification
validation_status	Current lifecycle status
owner	Accountability assignment
description	Model purpose documentation
approved_use_cases	Sanctioned use documentation
restrictions	Conditional approval constraints
created_at / updated_at	Registry lifecycle dates
usage_30d / usage_90d	Ongoing monitoring evidence
last_used_at	Last production activity

Export the inventory before each examination. For examination submissions, use format=csv for direct import into GRC platforms or examiner workbooks.

Approval history audit trail

For each model of interest, provide the complete validation history:

GET /api/v1/admin/models/{entry_id}/status/history

Each log entry is immutable and contains:

• Who performed the transition (admin user_id)
• The old and new statuses
• The reason text documenting the decision
• The timestamp (changed_at)

Approval log records cannot be edited or deleted. This tamper-evident trail demonstrates the validation governance chain required under SR 11-7.

Usage statistics as ongoing monitoring evidence

The usage_30d and usage_90d fields in the inventory export directly address SR 11-7’s ongoing monitoring requirement. Present these to demonstrate:

• Models in production are being actively monitored
• Models that are approved but show zero usage may indicate a stale registry entry
• Models that show unexpectedly high usage may warrant review of the approved use case scope

Demonstrating policy enforcement

Export a sample of audit log entries showing CANCEL and PROMPT actions on model_risk_tier conditions to demonstrate that:

• Unvalidated models are blocked at the gateway level
• High-risk model access requires user acknowledgment
• Deprecated models are actively prevented from being used

Audit entries reference the rule ID, pack ID, and matched condition, creating a direct link between the governance policy and the enforcement event.

Sample examination questions

The following questions are representative of SR 11-7 focused examination requests. Each includes where to find the evidence in Arbitex.

Examiner question	Arbitex evidence source
“Provide a complete inventory of AI models in use.”	GET /api/v1/admin/model-inventory-export?format=csv
“How are AI models classified by risk?”	Inventory export, risk_tier field. Point to tier definitions in your MRM policy.
“Who is responsible for each AI model?”	Inventory export, owner field
“What is the validation status of [model X]?”	Inventory export filtered by model_id, or registry detail view in Admin portal
“Who approved [model X] for production use and when?”	GET /api/v1/admin/models/{id}/status/history — approval log
“What conditions apply to the conditional approval for [model X]?”	Registry entry restrictions field
“How do you prevent unvalidated models from being used?”	Policy Engine configuration — CANCEL rule for unclassified tier models
“How do you monitor AI model usage after approval?”	Inventory export usage_30d, usage_90d, last_used_at fields
“How do you handle model retirement?”	Validation history showing deprecated transition + Policy Engine CANCEL rule
“Is your model inventory complete?”	Auto-discovery log — demonstrate daily discovery cycle has run and inventory is current

Pre-examination readiness checklist

Complete this checklist before each SR 11-7 examination cycle:

Inventory completeness:

• Run on-demand discovery to capture any models not yet in the registry
• No models remain in unclassified status beyond 30 days without a documented triage decision
• All approved and conditional models have owners assigned
• All conditional models have restrictions populated

Validation documentation:

• All critical and high tier models have complete validation history in the approval log
• Approval log entries contain substantive reason text (not just “approved”)
• No critical or high tier models are in unclassified status in production

Policy enforcement:

• Policy Engine includes a rule blocking unclassified models for general users
• Policy Engine includes a rule blocking deprecated models
• critical and high tier models have governance prompt or access restriction rules in place

Ongoing monitoring:

• Recent inventory export shows non-zero usage stats for models with expected production activity
• Revalidation has been submitted for models that have reached their periodic review deadline
• No models show usage patterns inconsistent with approved use cases

---

Ongoing monitoring program

SR 11-7 requires institutions to monitor model performance and usage continuously after approval. The following program structure implements this requirement using Arbitex capabilities.

Revalidation cadence by tier

Tier	Revalidation period	Trigger
critical	Quarterly	Calendar-driven + material change trigger
high	Semi-annual	Calendar-driven + material change trigger
medium	Annual	Calendar-driven
low	Biennial	Calendar-driven

A material change trigger applies regardless of calendar period when:

• The AI model version changes (e.g., provider upgrades from gpt-4o to gpt-4o-2025)
• The approved use case scope expands materially
• A significant performance concern is identified
• An examiner or internal audit finding relates to the model

Revalidation follows the same lifecycle: transition back to under_review with a documented reason, complete validation, and transition to approved or conditional.

Usage monitoring thresholds

Review inventory export data on the following schedule:

Tier	Usage review frequency	Escalation threshold
critical	Monthly	Usage decrease >50% MoM or increase >100% MoM
high	Monthly	Usage decrease >50% MoM or increase >200% MoM
medium	Quarterly	Unexpected zero-usage periods
low	Annually	No specific threshold — confirm model is still in use

When a usage anomaly is detected:

1. Review audit log entries for the model to identify usage patterns
2. Determine if usage outside approved use cases is occurring
3. Document the finding in the model’s registry entry description
4. Escalate per the procedures below if a policy violation is confirmed

Drift detection

AI model drift in the SR 11-7 context means the model is being used outside its approved use cases, or the model’s provider has updated the underlying model in ways that may affect its suitability for the approved use.

Use case drift indicators:

• Audit log shows usage by user groups not included in the approved use cases
• Prompt patterns observed in audit data are inconsistent with the documented use case
• Volume spikes in business areas not listed as owners

Model version drift:

• Configure alerts in your SIEM for audit log entries where model_id includes a new version suffix not in your registry
• When a new model version is detected, initiate triage and validation before approving it for production

Dashboard and alert configuration

Configure your SIEM (via OCSF export) to alert on the following conditions:

Alert	SIEM filter	Action
Unvalidated model accessed	model_risk_tier = unclassified AND action = ALLOW	Immediate investigation — policy may not be blocking unvalidated models
Deprecated model access attempt	model_risk_tier rule match AND model status = deprecated	Verify CANCEL rule is active
critical model usage spike	model_id in critical tier AND usage_30d > threshold	Review audit log for use case consistency
Revalidation deadline approaching	Internal calendar check against updated_at and tier cadence	Initiate under_review transition

Escalation procedures

Finding	Escalation path
Unvalidated critical model in production use	Immediate: Model Risk Officer + CRO notification; suspend access via Policy Engine
conditional model used outside restrictions	Same-day: Model owner + Model Risk Officer; update policy rules to enforce restriction
Failed revalidation at critical tier	Same-day: CRO notification; evaluate whether to deprecate or restrict while re-validation is in progress
Examiner finding related to a model	Immediate: General Counsel + CRO; document in registry entry; initiate remediation
New model version detected without registry entry	Within 5 business days: triage and initiate validation before approving

---

Roles and responsibilities

The following RACI matrix defines accountability for model risk management activities across the platform. A = Accountable, R = Responsible, C = Consulted, I = Informed.

Activity	Model Owner	Model Risk Team / Validators	Line of Business	Internal Audit	Platform Admin
Register model in registry	R	C	I	I	—
Assign risk tier and use cases	R	C	C	I	—
Submit for review	R	I	I	I	—
Perform independent validation	—	A/R	C	I	—
Approve / conditionally approve model	—	A/R	I	I	—
Update restrictions for conditional models	—	A	R	I	I
Configure Policy Engine enforcement rules	C	C	C	I	A/R
Monitor usage statistics	R	C	C	I	—
Initiate revalidation	R	I	I	I	—
Deprecate model	R	C	I	I	I
Export inventory for examination	—	C	—	R	R
Conduct MRM program audit	I	C	I	A/R	I
Escalate critical findings	R	A	R	R	I

Role definitions:

Model owner — The team or individual registered as owner in the registry entry. Accountable for maintaining accurate registry metadata, initiating lifecycle transitions, and monitoring the model’s usage against approved use cases.

Model risk team / validators — Independent validators responsible for assessing conceptual soundness, data quality, and performance per SR 11-7. Accountable for approval decisions and the content of approval log entries.

Line of business — The business unit using the model. Responsible for ensuring usage is consistent with approved use cases and escalating concerns to the model owner.

Internal audit — Independently tests the effectiveness of the MRM program. Reviews the completeness and accuracy of the registry, the adequacy of validation documentation, and the effectiveness of Policy Engine controls.

Platform admin — Manages platform configuration, including Policy Engine rule deployment, user group assignments, and SIEM integration. Does not make model risk decisions but implements the technical controls defined by the model risk team.

---

See also

• Model Registry technical reference — API endpoints, request/response schemas, state machine, and auto-discovery
• Compliance Bundles — Pre-built policy packs for PCI-DSS, HIPAA, GLBA, and other frameworks
• Compliance Frameworks Reference — How Arbitex controls map to GLBA, BSA/AML, SOX, and other financial services regulations
• Policy Engine Deep Dive — Condition types, combining algorithms, and rule interaction
• Audit Log Management — Understanding audit events used by auto-discovery and ongoing monitoring