Model Risk Management (MRM) Validator

The MRM Validator holds your model inventory and runs the validation and ongoing monitoring tests that SR 11-7 expects, from performance and stability to drift and fair lending bias analysis, on credit scoring, AI and other models. Validators review the results, record findings and their conclusions, and model owners track remediation. Every test, finding and approval keeps its data, code version and reasoning, ready for model risk committees, auditors and examiners.

The problem it solves

Most model risk teams keep the inventory in a spreadsheet, validation reports in shared folders, and monitoring results in whatever each model developer produced. Validators rebuild the same tests for every model, drift is noticed at the annual review rather than when it starts, and bias testing is done differently by each team. When examiners ask for the evidence behind a validation conclusion, or how a finding was closed, the team assembles it by hand from documents, emails and code that may have changed since.

Who it’s for

• Model risk management teams at banks, credit unions and lenders
• Model validators who provide effective challenge
• Model owners and developers of credit scoring, fraud, AML, CECL, stress testing and AI models
• Fair lending and compliance teams who test models for disparate impact
• Model risk committees, internal audit and examiners

1. InventoryEvery model and model-like tool is recorded with its owner, purpose, use, data, risk tier and validation status, so the institution knows what it relies on and where the gaps are.
2. ValidateValidators plan the validation, run standard tests against the model's development and outcome data, and record their own analysis and challenge alongside the results.
3. MonitorBetween validations, scheduled monitoring compares the model's current inputs, scores and outcomes with its development baseline, and flags drift and bias for review.
4. Remediate and approveFindings are tracked to closure with the owner's response and evidence. Validation conclusions and model approvals go through the governance steps your policy sets.

Model inventory

One inventory of models and model-like tools, with owners, uses, dependencies, risk tier and validation status, including vendor models.

Risk tiering

Materiality and complexity questions propose a tier, which model risk management confirms or changes with a reason.

Test library

Standard tests for discrimination, calibration, stability, sensitivity, back-testing and benchmarking, each documented with its method and interpretation.

Reproducible test runs

Each run records the data snapshot, model version, code version and parameters, so it can be repeated and gives the same result.

Drift monitoring

Population stability, characteristic stability and performance measures tracked against each model's baseline, with thresholds you set.

Bias and fair lending analysis

Outcome and score comparisons across groups, using the methods and proxy approaches your fair lending program defines, with results kept for review.

Explainability reports

Variable importance and reason-code analysis for complex and machine learning models, to support conceptual soundness review and adverse action reasons.

Findings and remediation

Findings with severity, owner, due date and action plan, tracked to closure with evidence and validator sign-off.

Validation report builder

A validation report assembled from the plan, tests, analysis and findings, which the validator edits and finalizes.

AI-assisted review

Suggested gaps in model documentation and draft summaries of test results for the validator to check; validators make every conclusion.

Governance workflow

Approvals for tiers, validation conclusions, conditions on use and exceptions, following your policy's levels and committees.

Audit trail

Every inventory change, test run, finding, approval and export recorded with the person and time.

Model owner

Registers models, supplies documentation and data, and remediates findings

Model validator

Plans and performs validations, runs tests and raises findings

Head of model risk

Confirms tiers, approves validation conclusions and oversees the program

Fair lending analyst

Defines and reviews bias testing for credit models

Model risk committee member

Reviews program reporting and approves high-risk models and exceptions

Auditor or examiner (read-only)

Views the inventory, validations, findings and audit trail without changing them

Data warehouse and data lake

Development, scoring and outcome data read from your warehouse or lake by scheduled query or file, mapped during implementation.

Model development environments

Test runs can call your own Python or R code, and model artifacts and versions can be read from your model registry.

Code repositories

The code version behind each model and test run linked from your Git repository.

Moraph products

Scenario and model documentation shared with the AML & SAR Automation Hub, the IFRS 9 / CECL Impairment Calculator and Stress Testing & Capital Planning (DFAST).

GRC and issue management

Findings and their status shared with your governance, risk and compliance system so issues are tracked in one place.

Single sign-on

Staff sign in through your identity provider (SAML or OpenID Connect).

Work API

Inventory, validation and monitoring data available to your data warehouse and reporting tools through the Moraph Work API.

Single sign-on

Staff sign in through your identity provider, so your password and multi-factor policies apply.

Role-based access

What each person can see and do follows their role; validators are independent of the models they validate, and owners cannot approve their own models.

Restricted test data

Access to customer-level data and protected-class analysis is limited to the roles you choose; most users see aggregate results only.

Encryption and keys

Client data is encrypted, with keys Moraph staff cannot use without explicit, time-bound authorization.

Complete audit trail

Every view, change, test run, decision and export is logged with the person and time, and cannot be edited.

Data residency

Data stays in the hosting region you choose: the United States, the United Kingdom or Australia.

Moraph cloud

Hosted and operated by Moraph in the United States region. United Kingdom and Australia regions are available for institutions outside the US.

Dedicated environment

A single-tenant environment for institutions whose policies require isolation, scoped in the proposal.

Tests run near your data

Where customer-level data must stay in your environment, test runs can execute there and return only results to the Validator, scoped in the proposal.

Inventory load

We load your existing inventory, validation history and open findings, and help owners fill the gaps. We need your current inventory and policy, and a contact in model risk management.

Policy configuration

Risk tiers, validation frequencies, approval levels, finding severities and committee steps are configured from your model risk policy.

Data connections

Development, scoring and outcome data for the first models are connected and their baselines recorded.

Test configuration

Tests and thresholds are set for each model type, and your own test code is added where you use it.

Pilot validations

A small number of models are validated or monitored in the Validator alongside your current process, and the results compared.

Training and go-live

Owners, validators, fair lending staff and approvers are trained on their own workflows, and further models are onboarded in the order you choose.

• The Validator does not validate models by itself. It runs tests, organizes evidence and suggests gaps; your validators provide the effective challenge and reach every conclusion.
• AI-generated summaries and gap suggestions are drafts for a validator to check. They are not findings until a person records them.
• Test results depend on the data you provide. Incomplete outcome data or a poorly defined baseline will limit what monitoring can show.
• Bias testing uses the groups, proxy methods and measures your fair lending program defines. The Validator does not determine whether a model complies with fair lending law; that is your institution's judgment, with counsel where needed.
• It is not a model development platform. Models are built and deployed in your own environments.
• Vendor models can be inventoried and monitored on their outputs, but their internal logic can be reviewed only as far as the vendor's documentation allows.
• It does not replace your model risk policy or committee. Tiers, thresholds and conditions on use are your institution's decisions, recorded in the Validator.

• Load your current inventory and see what the tiering questions propose against your own tiers
• Run the standard tests on one model's development and recent outcome data and compare them with your last validation
• Re-run a test a week later and confirm it gives the same result from the recorded data and versions
• Review a drift alert and decide whether it gives the owner and validator enough to act on
• Walk a finding from raise to closure and check the evidence it leaves
• Confirm independence: who can validate, approve and change a model's tier