KumoRFM Fine-Tuning PlatformAdmin & SetupSecurity and Compliance

Model Risk Management

View as Markdown

Kumo and MRM

Model Risk Management (MRM) refers to the set of regulations in the financial industry that control the design and deployment of machine learning models, such as SR 11-7 (USA), SS3/8 (UK), IFRS 9, and others.

While MRM provides many benefits to society by ensuring that ML is used safely and fairly, data scientists often view it as a burden, as they need to go through a heavyweight audit and review process for every new model they develop.

Kumo helps data scientists save time during the MRM audit process. All information that is typically needed for the MRM audit is available in the Kumo UI, API, or public documentation.

This datasheet highlights the set of capabilities within Kumo that you can use to support a typical MRM process, such as the one outlined in the OCC’s revised model risk management guidance. The sections in this datasheet correspond to common model risk management activities.

Governance

The Governance section of the Comptroller’s Handbook describes the organizational structure, tooling, and people-processes that are typically required to implement Risk Management within a large organization. Kumo recommends using a separate compliance platform to run your MRM governance program as a whole. As described in subsequent sections, Kumo provides documentation, validation, and IT controls so that you can efficiently audit and safely deploy all models built with Kumo.

Model Development and Implementation

The first thing a data scientist does during MRM is to prove that “the design, theory, and logic underlying the model” are sound and appropriate for the business problem.

In practice, this involves documenting the rationale for all components of model design, such as (1) the reasons for using specific tables and columns as an input to the model, and any pre-processing of these features (2) the choice of final model architecture, including tests that were run that led to the selection of the final architecture.

Kumo has several capabilities that simplify this documentation process, such as:

  • Model Architecture Export: Ability to view the final model architecture in human-readable format, including the specific GNN architecture that was selected by AutoML, and the encoding (one-hot, scaling, null-value handling, and so on) applied to every single column in the input data.
  • Data Quality Checks: Distribution statistics, graphs, and automatic data-quality checks for each input column, enabling a human to confirm that the data matches business expectations, and has sufficient trustworthiness and suitability.
  • Benchmarks: Academic research papers benchmarking GNN model architecture against leading alternatives, demonstrating the theoretical soundness of Kumo’s approach to tabular machine learning.
  • Architecture Search History: When using AutoML, Kumo records the architecture and hyperparameter search history, along with the performance for each combination, helping the data scientist document why the chosen architecture is sound.

Model Use

In the Comptroller’s Handbook, the “Model Use” section focuses on understanding any additional risks and limitations related to the model’s use in production, such as any post-processing or overlays applied on the predictions, or whether the assumptions made by the model reflect reality.

Most of this does not directly relate to the ML model itself, but there are a few areas where Kumo can help:

  • Sensitivity Analysis: You can provide a custom scoring table to Kumo at batch prediction time to enable sensitivity analysis.
  • Prediction Explainability: Kumo can generate human-interpretable explanations of individual predictions. This enables you to verify the reason behind each prediction, rather than blindly trusting the predicted score.

Model Validation

A sound model validation process ensures that a model performs as expected, including input data, processing, and reporting. This typically starts with a rigorous evaluation of model correctness prior to the deployment of the first version, including an outcomes analysis by backtesting on a holdout dataset. After the model is in production, ongoing validation is needed to ensure continued correctness of the model predictions, a practice often known as MLOps.

Kumo offers many capabilities around model evaluation, including:

  • Learning Curves and Distribution: Enables monitoring of convergence rates (to detect under/overfitting), and that the distribution of training data is well-balanced over time.
  • Backtesting on Holdout: All models are back-tested on a configurable holdout dataset. You can download this holdout for custom analysis.
  • Standard Eval Metrics and Charts: Including: ROC and PRC curve, cumulative gain chart, AUPRC, AUROC, predicted vs actual scatter plot and histogram, MAE, MSE, RMSE, SMAPE, average precision, AUPRC, per-category recall, F1, MAP
  • Baseline Comparison: Models are benchmarked against an automatically generated analytic baseline.
  • Column Explainability: A visualization similar to Partial Dependence Plots, highlighting which columns have the greatest predictive power. This helps prove that the model has no data leakage.

To support ongoing validation of model correctness, Kumo provides the following MLOps features:

  • Data Source Snapshotting: During each job, Kumo snapshots data source statistics (including size, time range, and import time), enabling faster root cause analysis.
  • Drift Detection: Kumo records and monitors distributions of features and predictions over time, enabling early detection of issues and preventing bad predictions from being published to production.
  • Champion/Challenger: If orchestrating automatic job retraining through the REST API, you can adopt a champion/challenger approach to validate the key metrics of the newly retrained model.

Third Party Risk Management

When engaging with a third-party vendor for modeling, additional restrictions may apply. Most importantly, banks should maintain as much knowledge in-house as possible, in case the vendor or bank terminates the contract for any reason.

Because Kumo lets organizations train their own models, all knowledge on how to build your specific model, as well as the data used to train the model, remains under the organization’s control. As such, satisfying this aspect of the MRM requirements is typically much easier, compared to a vendor that sells a specific model or dataset as a service.

IT Systems

MRM typically requires that the IT systems used to train and serve models meet your organization’s needs around availability and security.

Kumo relies on industry-standard information security best practices and compliance frameworks, such as NIST 800-53 and the ISO 27000 series. Kumo is SOC 2 Type II compliant, and provides several standard deployment offerings to meet the needs of various security teams. Custom offerings are available upon request:

  • SaaS: Kumo manages the cloud infrastructure GPU compute, data processing platform, and temporary data cache for model training. All data in flight and at rest is encrypted and protected according to principle of least access.
  • Snowflake Native: The Kumo Application can run as a Native App within an organization’s Snowflake account. In this configuration, all data and compute remains within the organization’s Snowflake account and VPC, analogous to an on-prem deployment.
  • Databricks Native: Kumo serves the control plane and GPU compute from a Kumo-managed environment, while all data processing and storage is pushed down to the organization’s Databricks account and VPC. No raw data is persisted outside of the Databricks environment.