Financial Services · Moraph software

Model Risk Management (MRM) Validator

Keep the model inventory, run validation tests, and evidence effective challenge, in one place

Book a demonstrationRequest a technical briefingFactsheet

Overview

What you are buying

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.

  • The model inventory is incomplete, out of date or held in several places
  • Validation tests are rebuilt by hand for each model and are hard to reproduce
  • Performance drift and population shifts are found late, at periodic review
  • Findings, remediation and approvals are tracked in documents and email

Who uses it

  • 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

Requirements it supports

Supervisory Guidance on Model Risk Management (Federal Reserve SR 11-7 and OCC Bulletin 2011-12)OCC Comptroller's Handbook: Model Risk ManagementFDIC adoption of the model risk management guidance (FIL-22-2017)Equal Credit Opportunity Act and Regulation B (12 CFR Part 1002)CFPB Circular 2022-03: adverse action notices and complex algorithmsNIST AI Risk Management Framework (AI RMF 1.0), as a voluntary reference

The product supports these requirements; meeting them remains your organization’s responsibility.

See how it works

A short walkthrough

Illustrative screens with fictional sample data. They show the workflow, not any client’s data or configuration, and the layout of the product itself differs. A live demonstration uses the product with sample data.

  1. Step 1

    The model inventory

    Model risk management starts from one inventory, showing each model's tier, owner and validation status.

    ModelUseTierOwnerLast validationStatus
    MD-0142 Consumer credit score v4Credit decisioningTier 1Consumer lending11 months agoValidation due
    MD-0157 Card fraud score (machine learning)Fraud detectionTier 1Fraud operations5 months agoDrift alert
    MD-0118 CECL loss model, commercialAllowanceTier 1Finance7 months agoApproved with conditions
    MD-0163 AML structuring scenario setTransaction monitoringTier 2BSA/AML9 months agoApproved
    MD-0171 Deposit pricing tool (vendor)PricingTier 3TreasuryNoneTiering in review
    Model risk management starts from one inventory, showing each model's tier, owner and validation status.

  2. Step 2

    A model's record

    Everything known about a model sits on one record: purpose, data, versions, dependencies and open findings.

    MD-0142 · Consumer credit score v4 (fictional)

    Purpose
    Approve or decline unsecured consumer loans
    Model type
    Gradient boosted trees
    Current version
    4.2, deployed 14 months ago
    Risk tier
    Tier 1, confirmed by model risk
    Open findings
    2, one high
    Next validation
    Due next month

    Dependencies

    • Bureau attributes feed (vendor data)
    • Income estimation model MD-0139
    • Adverse action reason code mapping
    Everything known about a model sits on one record: purpose, data, versions, dependencies and open findings.

  3. Step 3

    Drift monitoring

    Monthly monitoring compares the model's current population and performance with its development baseline.

    MeasureBaselineLast monthThis monthThresholdResult
    Population stability index0.000.080.270.25Breach
    Area under the curve0.910.900.860.85Watch
    Fraud capture at review rate68%66%61%60%Watch
    Characteristic stability: merchant category0.000.050.310.25Breach
    Monthly monitoring compares the model's current population and performance with its development baseline.

  4. Step 4

    Fair lending analysis

    Bias tests run with the groups and methods your fair lending program defines, and the analyst records the review.

    MD-0142 · Approval outcomes, fictional sample period

    Method
    Adverse impact ratio, with proxy method set by your program
    Applications analyzed
    48,210
    Lowest group ratio
    0.78
    Program threshold
    0.80
    Reviewed by
    Fair lending analyst

    Follow-up

    • Identify variables driving the difference
    • Search for less discriminatory alternatives with the model owner
    • Refer result to the head of model risk and compliance
    Bias tests run with the groups and methods your fair lending program defines, and the analyst records the review.

  5. Step 5

    The validation

    Each validation keeps its plan, tests, the validator's challenge and the approval of its conclusion.

    Validation VL-2209 · MD-0142 annual validation

    1. Validation plan approved for Tier 1 scopeHead of model risk
    2. Documentation, data snapshot and code version attachedModel owner
    3. Discrimination, calibration and stability tests runModel validator
    4. Documentation gaps suggested for reviewAI assistant
    5. Conceptual soundness review and benchmark challenger recordedModel validator
    6. Two findings raised; conclusion: approved with conditionsModel validator
    7. Conclusion approvedHead of model risk
    Each validation keeps its plan, tests, the validator's challenge and the approval of its conclusion.

  6. Step 6

    Findings to closure

    Every finding has an owner, a plan and a due date, and closes only when the validator accepts the evidence.

    FindingModelSeverityOwnerDueStatus
    FN-0912 Recalibrate after population shiftMD-0157HighFraud operationsNext monthPlan agreed
    FN-0907 Document reason code mappingMD-0142MediumConsumer lendingThis quarterEvidence submitted
    FN-0906 Adverse impact ratio below thresholdMD-0142HighConsumer lendingOverdueIn remediation
    FN-0884 Vendor documentation incompleteMD-0171LowTreasuryNext quarterOpen
    Every finding has an owner, a plan and a due date, and closes only when the validator accepts the evidence.

Workflows

The principal workflows

  1. Inventory

    Every 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.

    • Models registered by owners or imported from existing inventories
    • Purpose, uses, inputs, outputs and dependencies recorded
    • Risk tier proposed from materiality and complexity questions
    • Tier confirmed by model risk management
    • Validation and review schedule set from the tier

  2. Validate

    Validators plan the validation, run standard tests against the model's development and outcome data, and record their own analysis and challenge alongside the results.

    • Validation scope and plan agreed for the model's tier
    • Model documentation, data and code version attached
    • Standard tests run: discrimination, calibration, stability, sensitivity and benchmarking
    • Validator records conceptual soundness review and effective challenge
    • Findings raised with severity, owner and due date

  3. Monitor

    Between validations, scheduled monitoring compares the model's current inputs, scores and outcomes with its development baseline, and flags drift and bias for review.

    • Scoring and outcome data arrive on your schedule
    • Population stability and characteristic stability measured against the baseline
    • Performance measures compared with thresholds set for the model
    • Fair lending tests run on the groups and methods your program defines
    • Breaches routed to the model owner and validator with the analysis behind them

  4. Remediate and approve

    Findings 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 owner responds to each finding with an action plan
    • Evidence of remediation attached and reviewed by the validator
    • Validation report assembled from the plan, tests and findings
    • Head of model risk approves the conclusion and any conditions on use
    • Model risk committee informed or approves, as your policy requires

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Model owner

Model owner, model developer, business line analytics lead

Is accountable for a model's use and performance: registers it, supplies documentation and data, and remediates findings.

Sees

  • Their own models' records, monitoring results and validations
  • Findings raised on their models
  • Validation reports for their models once finalized

Does

  • Registers new models and changes to existing ones
  • Attaches documentation, data snapshots and code versions
  • Answers tiering questions
  • Responds to findings with action plans and evidence
  • Requests exceptions or conditions on use

Cannot

  • Validate their own models or close their own findings
  • Change a model's confirmed tier
  • Approve a model for use
Approvals
Their tiers, remediation evidence and exception requests are reviewed by validators and model risk management.
Notified about
Validations scheduled for their models, monitoring breaches, new findings and findings approaching their due date.

Model validator

Model validator, quantitative analyst, model risk analyst

Provides independent, effective challenge: plans and performs validations, runs tests and raises findings.

Sees

  • Models assigned to them for validation and their full records
  • Development and monitoring data within their access
  • Test results, earlier validations and open findings

Does

  • Writes the validation plan and scope
  • Runs standard and custom tests
  • Records the conceptual soundness review and benchmark analysis
  • Raises findings with severity and due date
  • Accepts or rejects remediation evidence
  • Drafts the validation report and conclusion

Cannot

  • Validate a model they developed or own
  • Approve their own validation conclusion
  • Edit a test run after it is recorded
Approvals
Their validation plans and conclusions are approved by the head of model risk.
Notified about
Validations assigned to them, remediation evidence submitted and monitoring breaches on models they cover.

Head of model risk

Head of model risk management, chief model risk officer, director of model validation

Owns the model risk program: confirms tiers, approves validation conclusions and conditions on use, and reports to the committee.

Sees

  • The whole inventory, every validation and finding
  • Program reporting: validations due, findings by age, monitoring breaches
  • Policy configuration and its change history
  • The full audit trail

Does

  • Confirms or changes risk tiers
  • Approves validation plans and conclusions
  • Sets conditions on use and approves exceptions within their authority
  • Assigns validators, keeping them independent of the models
  • Prepares committee and board reporting

Cannot

  • Approve a validation they performed themselves; a second approver is required
  • Edit or delete entries in the audit trail
  • Change recorded test results
Approvals
Approves tiers, validation conclusions, conditions and exceptions within their authority; higher-risk items go to the model risk committee.
Notified about
Conclusions waiting for approval, high-severity findings, overdue findings and monitoring breaches on Tier 1 models.

Fair lending analyst

Fair lending officer, fair lending analyst, compliance analytics

Defines how credit models are tested for disparate impact and reviews the results.

Sees

  • Credit models and their fair lending test results
  • Protected-class analysis and proxy results, where granted
  • Findings raised from fair lending tests

Does

  • Sets the groups, proxy methods, measures and thresholds for bias tests
  • Reviews test results and records their analysis
  • Raises fair lending findings
  • Works with owners on less discriminatory alternatives

Cannot

  • Approve a model for use
  • Change a model's tier
  • Close findings without validator acceptance
Approvals
Changes to bias test methods and thresholds are approved by the head of model risk together with compliance.
Notified about
Fair lending test results below threshold and findings they raised approaching their due date.

Model risk committee member

Chief risk officer, chief credit officer, committee members

Oversees model risk across the institution and approves high-risk models and exceptions as policy requires.

Sees

  • Program reporting and the inventory
  • Items on the committee's agenda with their validations and findings
  • Decisions from earlier meetings

Does

  • Approves or declines items referred to the committee
  • Records committee decisions and conditions
  • Requests further analysis

Cannot

  • Change tests, findings or validation reports
  • Approve an item for a model they own
Approvals
Committee decisions are recorded with the members present, as your charter requires.
Notified about
Items referred to the committee and the meeting pack when it is ready.

Auditor or examiner (read-only)

Internal auditor, external auditor, regulatory examiner (under temporary access)

Reviews the program's inventory, validations and decisions without being able to change anything.

Sees

  • The inventory, validations, test runs and findings within the scope granted
  • Committee decisions and program reports
  • The audit trail

Does

  • Searches and reads records within their scope
  • Re-runs recorded tests in read-only mode to confirm results, where granted
  • Exports records they have been given access to, with each export logged

Cannot

  • Change, approve or delete anything
  • See records outside the scope and dates granted
  • Keep access after it expires
Approvals
Their access is approved by the head of model risk or an administrator, with a scope and an end date.
Notified about
Nothing by default; access granted and expiring is confirmed to the person who approved it.

Administrator

Application administrator, risk systems administrator

Manages users, roles, data connections and configuration, without access to approve model decisions.

Sees

  • Users, roles and teams
  • Data connection and integration settings
  • The record of permission changes

Does

  • Adds and removes users, or maps them from single sign-on groups
  • Assigns roles
  • Maintains data connections and integration settings
  • Runs access review reports

Cannot

  • Approve tiers, validations or findings
  • See protected-class analysis unless granted
  • Grant themselves a model risk role without the head of model risk
Approvals
Role changes that grant approval rights or access to customer-level data are approved by the head of model risk.
Notified about
Access reviews coming due, failed data loads and accounts not used for a period your policy sets.

Permissions at a glance

ActionOwnerValidatorHead of MRMFair lendingCommitteeAuditorAdmin
Register or change a modelOwn work onlyNo accessFullNo accessNo accessNo accessNo access
Confirm a risk tierNo accessNo accessApprovesNo accessView onlyView onlyNo access
Run validation testsNo accessOwn work onlyFullOwn work onlyNo accessNo accessNo access
View customer-level test dataOwn work onlyOwn work onlyFullOwn work onlyNo accessNo accessNo access
Raise a findingNo accessOwn work onlyFullOwn work onlyNo accessNo accessNo access
Respond to a findingOwn work onlyNo accessFullNo accessNo accessNo accessNo access
Close a findingNo accessOwn work onlyApprovesNo accessNo accessNo accessNo access
Approve a validation conclusionNo accessNo accessApprovesNo accessApprovesView onlyNo access
Set bias test methodsNo accessNo accessApprovesFullNo accessView onlyNo access
Approve an exceptionNo accessNo accessApprovesNo accessApprovesView onlyNo access
View audit trailNo accessView onlyView onlyNo accessView onlyView onlyView only
Manage users and rolesNo accessNo accessApprovesNo accessNo accessNo accessFull
  • Full
  • Own work only
  • Approves
  • View only
  • No access

How access is controlled

  • Independence is built in: validators cannot be assigned models they develop or own, owners cannot close their own findings, and nobody approves a validation they performed.
  • Customer-level data and protected-class analysis are visible only to the roles you choose. Committee members and most other users see aggregate results.
  • Roles are configured with you during implementation. You can rename them, create custom roles, and limit them by business line or model type, and every permission change is recorded in the audit trail.
  • Staff sign in through your identity provider, and roles can follow its groups. Auditors and examiners get temporary read-only access with a defined scope and an end date, rather than shared accounts.

Features

What it does

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.

Integrations

How it connects to your systems

Connects toHowWhat flows
Data warehouse and data lakeDevelopment, scoring and outcome data read from your warehouse or lake by scheduled query or file, mapped during implementation.In: model inputs, scores, decisions and outcomes on your schedule.
Model development environmentsTest runs can call your own Python or R code, and model artifacts and versions can be read from your model registry.In: model versions, artifacts and development metrics.
Code repositoriesThe code version behind each model and test run linked from your Git repository.In: repository, branch and commit references.
Moraph productsScenario and model documentation shared with the AML & SAR Automation Hub, the IFRS 9 / CECL Impairment Calculator and Stress Testing & Capital Planning (DFAST).In: model versions, thresholds and results. Out: validation status and findings.
GRC and issue managementFindings and their status shared with your governance, risk and compliance system so issues are tracked in one place.Out: findings, owners, due dates and status.
Single sign-onStaff sign in through your identity provider (SAML or OpenID Connect).In: user identity and group membership for role assignment.
Work APIInventory, validation and monitoring data available to your data warehouse and reporting tools through the Moraph Work API.Out: models, tiers, test results, findings and approvals.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

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.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

11 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Inventory and coverage

Model inventory

For head of model risk, model risk committee, examiners

Every model and model-like tool with its owner, uses, tier, validation status and conditions on use.

Break down by
Tier, Business line, Model type, Vendor or internal, Validation status
Delivered as
Live view; PDF and CSV export
Used for
Knowing what the institution relies on and where validation coverage is missing.

Validation schedule

For head of model risk and validators

Validations due, in progress and overdue, with their assigned validator and scope.

Break down by
Tier, Validator, Due period, Status
Delivered as
Live dashboard; scheduled email; CSV export
Used for
Planning validation work and keeping every model within its review cycle.

Inventory changes

For head of model risk

Models added, retired or changed, and tier changes, in the period.

Break down by
Change type, Business line, Period
Delivered as
Live view; CSV export
Used for
Catching new or changed models that need validation before use.

Performance and monitoring

Monitoring results

For model owners, validators and the head of model risk

Stability, drift and performance measures for each monitored model against its thresholds, over time.

Break down by
Model, Measure, Period, Result
Delivered as
Live dashboard; PDF; CSV export
Used for
Acting on drift and performance decline between validations.

Fair lending test results

For fair lending analysts, head of model risk, compliance

Bias test results for credit models by group, method and period, with the analyst's review.

Break down by
Model, Measure, Group, Period
Delivered as
Live view; PDF and CSV export, restricted to permitted roles
Used for
Reviewing disparate impact risk and evidencing the testing program.

Threshold breaches

For model owners and validators

Every monitoring breach, when it occurred, and what was decided about it.

Break down by
Model, Measure, Decision, Period
Delivered as
Live dashboard; scheduled email
Used for
Making sure no breach goes without a recorded response.

Findings and governance

Open findings

For head of model risk, model owners, committee

Open findings with severity, owner, due date, action plan and status.

Break down by
Severity, Owner, Model, Age band, Status
Delivered as
Live dashboard; PDF; CSV export
Used for
Driving remediation and reporting overdue findings.

Program summary

For model risk committee and the board

A periodic summary of inventory size and tiers, validations completed, findings opened and closed, monitoring breaches and exceptions.

Break down by
Period, Business line, Tier
Delivered as
PDF; scheduled email
Used for
Giving the committee and board the information they need to oversee model risk.

Exceptions and conditions on use

For head of model risk and committee

Models in use with exceptions or conditions, who approved them, and when they expire.

Break down by
Model, Condition type, Approver, Expiry
Delivered as
Live view; PDF and CSV export
Used for
Making sure temporary exceptions are reviewed before they lapse.

Regulatory and audit

Validation evidence pack

For internal audit and examiners

For a selected model, the validation plan, test runs with data and code versions, findings, report and approvals.

Break down by
Model, Validation, Date range
Delivered as
On request in the product; PDF export
Used for
Answering examiner requests about a specific validation without assembling it by hand.

Audit trail extract

For internal audit and examiners

Who did what, when and why for a selected model, validation or period, including test runs, findings and approvals.

Break down by
Record, User, Action, Date range
Delivered as
On request in the product; CSV and PDF export
Used for
Providing evidence of independence and approvals across the program.

Exports, access and evidence

  • Every report can be exported to CSV, and summary and evidence reports to PDF. Reports can be scheduled to arrive by email for the people entitled to see them.
  • Each report can be filtered by business line, tier and model type, and the filters saved, so validators, owners and the head of model risk can keep their own views.
  • Inventory, monitoring and findings data is available through the Moraph Work API, and can be delivered to your data warehouse or GRC system.
  • Reports respect each viewer's role: owners see their own models, fair lending results are limited to permitted roles, and examiners see only the scope they are granted.
  • Monitoring and validation reports can be run as of a past date and give the same result each time. Running and exporting a report is itself recorded in the audit trail.

Deployment

Where and how it runs

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.

Security controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

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.

Limitations

What it does not do

Worth knowing before you evaluate it.

  • 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.

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

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

Questions

Frequently asked questions

Who owns the data in the Validator?

Your institution does. How it is returned to you and deleted at the end of the agreement is set out in the contract.

Can we use our own validation tests and code?

Yes. The test library is a starting point, and your own Python or R tests can be added so they run, and are recorded, the same way.

Does the AI decide whether a model passes?

No. It can suggest documentation gaps and draft summaries of results. Validators decide every finding and conclusion, and approvals follow your policy.

Can it monitor vendor models?

Yes, on their inputs, outputs and outcomes. Review of their internal logic depends on what the vendor documents.

How is it priced?

As a subscription, usually measured by the number of models in the inventory and those under active monitoring, with implementation charged separately. See Working with Moraph for what drives a quotation.

Is there an accessibility conformance report?

Ask for one through the procurement request form at /how-to-buy/request, naming the version you are evaluating.

Next steps

Evaluate Model Risk Management (MRM) Validator

Book a demonstration

See the product working with sample data, focused on your workflows.

Request a demonstration

Request a technical briefing

Architecture, integrations, security and hosting, with our engineers and your technical team.

Request a briefing

Factsheet

This page on two sides, to share with colleagues or add to your evaluation file.

Open the factsheet

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: Model Risk Management (MRM) Validator guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: Model Risk Management (MRM) Validator support guide.

Related products