Model Monitoring and Drift Detection

Note: No direct handbook prerequisite. This chapter covers production monitoring for financial ML models where drift has regulatory consequences.

Your fraud model’s false negative rate was 0.3% at deployment. Six months later it is 0.7%. Nobody noticed because the aggregate precision metric on the weekly dashboard still looks healthy — the model is catching more true positives in absolute terms because transaction volume grew 40%. But the rate at which fraudulent transactions slip through has doubled, and the dollar value of undetected fraud has tripled. The regulator notices before you do, because their examination compares your SAR filing rate to peer institutions, and yours dropped.

Model drift in fintech is not an ML ops inconvenience. It is a compliance event, a financial loss, and a reputational risk. Detecting it requires monitoring the right signals at the right granularity — and acting before the quarterly model validation report surfaces a problem that has been compounding for months.

Two Kinds of Drift

Distribution drift (data drift) and concept drift are different failure modes with different detection methods.

Distribution drift means the inputs changed. The feature distributions your model trained on no longer match production. A fraud model trained when 60% of transactions were card-present now sees 80% card-not-present. The model’s decision boundary was optimized for a population that no longer exists.

Concept drift means the relationship between inputs and outputs changed. The same features now predict a different outcome. A credit model trained when unemployment was 3.5% still receives the same income and debt-to-income features, but the default probability for a given DTI ratio has shifted because the macroeconomic context changed. The inputs look identical; the correct labels are different.

Drift type What changed Detection signal Example
Distribution (covariate) Input feature distributions Statistical distance metrics on features Card-present ratio shifts from 60% to 30%
Prior probability Class balance Label rate monitoring Fraud rate doubles from 0.1% to 0.2%
Concept (real) Feature-target relationship Performance metric degradation Same DTI ratio, higher default rate
Concept (virtual) Feature-target relationship Statistical tests on prediction distributions Model confidence scores shift without label changes

Distribution drift is detectable immediately — you can compare feature distributions between training data and today’s production traffic without waiting for labels. Concept drift requires ground truth labels, which in financial systems arrive with delay: fraud labels take 30-90 days (chargeback windows), credit defaults take 6-18 months (loan maturity), and AML labels may never arrive at all (unreported suspicious activity produces no label).

The delay between prediction and label arrival is the core monitoring challenge. A fraud model making decisions today will not receive definitive feedback for 30-90 days. If concept drift began on day 1, you are flying blind until day 30 — and the financial damage accumulates every day.

Feature Distribution Monitoring

Track statistical distance between training distributions and production distributions for every input feature. The two standard metrics are Population Stability Index (PSI) and Kolmogorov-Smirnov (KS) statistic.

PSI bins the feature into deciles based on the training distribution, then compares the proportion in each bin between training and production.

def psi(expected, actual, bins=10):
    breakpoints = np.quantile(expected, np.linspace(0, 1, bins + 1))
    expected_pct = np.histogram(expected, breakpoints)[0] / len(expected)
    actual_pct = np.histogram(actual, breakpoints)[0] / len(actual)
    expected_pct = np.clip(expected_pct, 1e-4, None)
    actual_pct = np.clip(actual_pct, 1e-4, None)
    return np.sum((actual_pct - expected_pct) * np.log(actual_pct / expected_pct))
PSI value Interpretation Action
< 0.1 No significant shift None
0.1 – 0.25 Moderate shift Investigate
> 0.25 Significant shift Retrain or recalibrate

PSI works well for continuous features. For categorical features with many levels (merchant category codes, geography), use chi-squared tests or Jensen-Shannon divergence.

KS statistic measures the maximum distance between two cumulative distribution functions. It detects localized shifts that PSI’s binning might smooth over. A KS statistic above 0.05 with a p-value below 0.01 on a production sample of 10,000+ observations warrants investigation.

Monitor features daily for high-volume models (fraud, credit decisioning) and weekly for lower-volume models (underwriting, AML scoring). Compute PSI over rolling 7-day windows compared to the training reference set. Alert on the first day PSI exceeds 0.25 for any feature in the top 20 by importance.

Performance Monitoring

Feature drift tells you the inputs changed. Performance monitoring tells you whether the outputs are still correct. The gap between the two is the label delay.

For fraud models, track these metrics at daily and weekly granularity:

Metric Cadence Alert threshold Why it matters
False negative rate (FNR) Daily (lagged 30-90 days) > 1.5x baseline Undetected fraud, SAR filing gaps
False positive rate (FPR) Daily > 2x baseline Customer friction, operational cost
Precision at operating threshold Daily < 0.8x baseline Alert queue quality degrades
Score distribution (predicted probability) Daily (no label delay) PSI > 0.25 vs training Early signal before labels arrive
Dollar-weighted FNR Weekly (lagged) > 2x baseline Total fraud loss, not just count

The score distribution is the most valuable early signal because it requires no labels. If your fraud model’s predicted probability distribution shifts — more mass in the 0.3-0.5 range where it used to be bimodal at 0.05 and 0.95 — the model is less confident. Confidence degradation precedes accuracy degradation, and you can detect it on day 1 instead of day 30.

For credit models, the label delay is months to years. Use vintage analysis: group loans by origination month, track delinquency rates at 30/60/90 days past due, and compare across vintages. A vintage that delinquishes 20% faster than the model predicted at origination is evidence of concept drift, even before full default data arrives.

Segment-Level Monitoring

Aggregate metrics hide drift that concentrates in subpopulations. Your model’s overall precision may be stable at 0.85 while precision on transactions over $5,000 has dropped to 0.60. The high-dollar segment is where the dollar-weighted loss lives.

Slice performance by every dimension a regulator or business stakeholder cares about:

  • Transaction amount bands ($0-100, $100-1K, $1K-10K, $10K+)
  • Channel (card-present, card-not-present, ACH, wire)
  • Customer tenure (< 90 days, 90 days–1 year, > 1 year)
  • Geography (domestic, cross-border, high-risk jurisdictions)
  • Product line (checking, savings, lending, crypto)

A model that performs well in aggregate but poorly on new customers from high-risk geographies will eventually produce a fair lending finding. Segment-level monitoring catches this before the examination.

See Compliance Engineering. Regulatory examiners evaluate model performance on protected classes under ECOA and fair lending rules. Drift that disproportionately affects a protected class is not just a model problem — it is a legal exposure.

Automated Detection Pipelines

Manual dashboard reviews miss drift. A data scientist checking dashboards weekly will notice a sudden shift but miss a gradual one. Automated detection pipelines compute statistical tests on every batch of production data and fire alerts when thresholds are breached.

The pipeline runs on each scoring batch (or daily for streaming models):

1. Extract production features and scores (last 24 hours)
2. Compute PSI for each feature against training reference
3. Compute KS statistic for score distribution against training reference
4. If labels available: compute FNR, FPR, precision at operating threshold
5. Run segment-level slicing for all configured dimensions
6. Compare all metrics against thresholds
7. If any threshold breached: create alert with severity, affected segments, and trend

Severity classification determines routing:

Severity Criteria Response SLA Routing
P1 – Critical Performance metric > 2x baseline degradation 4 hours Model risk + on-call DS
P2 – High PSI > 0.25 on top-5 feature, or segment precision below threshold 24 hours Model owner
P3 – Medium PSI 0.1-0.25 on any feature, or score distribution shift 1 week Model owner review
P4 – Informational Minor shifts within normal variance Next review cycle Dashboard only

Proxy Metrics for Delayed Labels

When ground truth labels arrive in 30-90 days, you need proxy metrics that approximate model performance without labels.

Score stability — compare the distribution of model scores week over week. If the median predicted fraud probability shifts from 0.08 to 0.14, either fraud rates genuinely increased or the model is drifting. Both warrant investigation.

Upstream data quality — feature pipelines that degrade produce drift. A payment processor that changes its merchant category code taxonomy creates a feature distribution shift that is not real-world drift — it is data quality rot. Monitor the cardinality, null rate, and value distribution of every feature ingestion source.

Action rate — the fraction of model predictions that result in a downstream action (alert reviewed, transaction blocked, application declined). If your fraud model’s block rate increases 30% without a corresponding change in fraud reports, the model is likely over-triggering — the false positive rate increased.

Peer comparison — if your SAR filing rate drops below the 25th percentile for your peer group size and product mix, the model is missing cases that peer institutions are catching. FinCEN and OCC both use peer comparison in examinations.

Retraining Triggers and Governance

Drift detection triggers retraining, but financial models cannot be retrained and deployed without governance. SR 11-7 (the Federal Reserve’s model risk management guidance) requires independent validation before any model change goes to production.

The retraining decision matrix:

Signal Retrain? Governance gate
Feature PSI > 0.25, performance stable Investigate, schedule retrain Standard validation
Performance degradation > 1.5x on any segment Retrain with urgency Expedited validation (48-hour turnaround)
Concept drift confirmed (label data) Full retrain on updated data Full validation cycle (2-4 weeks)
Regulatory finding on model performance Retrain + remediation plan Board-level reporting, MRA response

A champion-challenger framework lets you train a challenger model on recent data and compare its performance against the production champion in shadow mode — scoring live traffic without acting on the results. Shadow scoring for 2-4 weeks generates enough data to validate the challenger without regulatory risk.

The critical governance constraint: you cannot retrain a model and silently deploy it. Every model change requires documentation of what changed (features, training data, hyperparameters), why (the drift evidence), what the validation showed (challenger vs champion on holdout data), and who approved deployment. The model inventory must reflect the current production version at all times.

A model that drifts is a known risk with a remediation path. A model that was silently retrained without validation is a governance failure. Regulators treat the second case as more severe than the first.

The Monitoring Stack

The infrastructure for model monitoring in production financial systems has three layers.

Data collection — capture every model input, output, and metadata (timestamp, model version, latency, feature source versions) for every prediction. Store in a columnar format (Parquet on S3, or a time-series database) with retention matching your longest label delay plus your regulatory audit window. For fraud models: 90 days label delay + 7 years audit retention = plan for 7+ years of prediction logs.

Computation — scheduled jobs (Airflow, Prefect) or streaming processors (Flink, Spark Structured Streaming) that compute drift metrics on each batch. For a fraud model scoring 500K transactions/day, daily PSI computation across 50 features on 7-day rolling windows runs in under 10 minutes on a single node.

Visualization and alerting — dashboards showing feature drift heatmaps, performance trends by segment, and score distribution comparisons. Grafana or custom dashboards backed by the metric store. Alerts route to PagerDuty for P1/P2, to Slack for P3/P4.

Purpose-built tools handle the computation and visualization layers. Evidently AI provides open-source drift detection with pre-built statistical tests. NannyML specializes in performance estimation without ground truth labels using confidence-based performance estimation (CBPE). Fiddler and Arthur provide commercial platforms with compliance-oriented audit trails. For teams that need full control over the statistical methods and governance workflow, building on open-source libraries (scipy.stats for KS tests, custom PSI implementations) and wrapping them in an internal monitoring service is common.

The cost of not monitoring is always higher than the cost of monitoring. A fraud model that drifts undetected for one quarter can generate more dollar loss than the entire annual budget of the model risk management team.