← Hub
AltScore Platform · ML Documentation
Model
Card
DOC-ID: MC-ALTSCORE-001
Model: AltScore Credit Scoring Engine v1
Version: 1.0  ·  May 2026
Classification: CONFIDENTIAL — NBFC Partners & Regulators
Owner: ML Engineering & Credit Risk, AltScore Technologies
XGBoost Primary Model Architecture Gradient-boosted tree ensemble; Croston's for sparse/seasonal retailers
300–900 AltScore Output Range Calibrated to CIBIL-equivalent scale; 4 risk bands A/B/C/D
40+ Engineered Features Across 5 families: payment, order, trajectory, seasonal, relationship
≥ 0.72 Minimum Acceptable AUROC KS ≥ 0.35 · PD calibration within ±2%
01 —

Overview & Purpose

The AltScore Credit Scoring Engine is a machine learning system that generates creditworthiness assessments for informal Indian retailers — small kiranas, pharmacies, and general merchants — who lack formal credit histories but have verifiable transactional relationships with FMCG distributors.

MC-ALTSCORE-001 · Model Purpose Statement

India's informal retail sector accounts for roughly ₹12 trillion in annual commerce, yet 12 million+ small retailers remain credit-invisible to traditional lenders. AltScore bridges this gap by transforming distributor ERP transaction data — invoices, payments, return rates, order cadence — into a structured creditworthiness signal that NBFC lending partners can underwrite against.

This Model Card documents the AltScore Credit Scoring Engine v1 in full compliance with RBI FLDG Guidelines (which mandate model transparency for co-lending arrangements), the DPDP Act 2023 (explainability obligations for automated decision-making), and emerging best practices for responsible AI in credit.

Primary Audience

NBFC Lending Partners

Integration guide and model transparency disclosure for credit underwriting teams consuming the Score API.

Regulatory Audience

RBI & DPDP Board

Demonstrating compliance with FLDG reason-code requirements, fair lending obligations, and automated decision-making transparency.

Internal Audience

ML & Risk Teams

Reference document for model monitoring, guardrail thresholds, drift detection, and champion/challenger protocol.

Scope of This Card

This card covers the primary XGBoost classifier used for retailers with ≥ 6 months of distributor transaction history. The Croston's Method sub-model (sparse/seasonal routing) and the Isolation Forest anomaly detector are described in Sections 04 and 07 respectively. Cold-start fallback scoring is covered under Limitations (Section 07).

02 —

Model Identity & Provenance

Model Name
AltScore Engine
Version
v1.0
Model ID
altscore-xgb-v1-prod
Algorithm Family
XGBoost
Task Type
Binary Classification
Output
Score + PD + Band + Codes
Explainability
SHAP TreeExplainer
Experiment Tracking
MLflow (self-managed)
Model Registry Hash
SHA-256 on artifact

Sub-Models

Sub-Model Algorithm Trigger Condition Output Status
Primary Scorer XGBoost v1.7 ≥6 months transaction history, completeness ≥70% PD (0–1), Score (300–900) Production
Sparse/Seasonal Router Croston's Method Intermittent order pattern OR high seasonal amplitude Adjusted order frequency; routes to modified XGB feature set Production
Anomaly Detector Isolation Forest Every scoring request; async gaming checks anomaly_score (0–1), flags {gaming, data_quality} Production
Explainability Layer SHAP TreeExplainer Every scored retailer reason_codes[] (≥5 categorical); SHAP values per feature Production
Cold-Start Fallback Rule-based conservative <6 months history OR completeness <50% Provisional score; ₹25K limit cap; low_confidence flag Production

Intended Deployment Context

The model is invoked exclusively via the Score API (POST /v1/score) by credentialed NBFC partners. It is not exposed to retailers directly and is never used in real-time decisioning without retailer consent being verified upstream. All scoring is performed in a managed cloud environment (AWS or Azure, India region) with no on-premises model deployment permitted.

03 —

Training Data

The model is trained on historical distributor-to-retailer transaction records combined with ground-truth repayment outcomes sourced from NBFC lending partners under data-sharing agreements. All training data is processed through the AltScore Data Lake Bronze → Silver pipeline before feature engineering.

Training Data Dependency

The quality of the AltScore model is directly bounded by the quality and representativeness of distributor ERP data. Retailers with a single distributor relationship, or those whose distributor uses non-standard ERP schema, will produce less reliable scores. See Limitations (Section 07).

Data Sources

Source Data Type Coverage Consent Basis Retention in Training
Tally Prime ERP Invoice history, payment ledger, GST filings Primary; ~60% of distributor base Retailer consent + distributor data partnership agreement Up to 36 months per retailer
SAP Business One Invoice history, payment terms, returns ~25% of distributor base Retailer consent + distributor data partnership agreement Up to 36 months per retailer
CSV/Manual Upload Structured invoice exports ~15% of distributor base Retailer consent + distributor data partnership agreement Up to 24 months (lower freshness)
NBFC Repayment Outcomes Loan disbursement + repayment status Pilot cohort (Phase 02 shadow lending) NBFC data sharing agreement; no retailer PII transferred 24-month performance window

Data Preprocessing Pipeline

Raw ERP data enters the Bronze layer as immutable append-only records protected by S3 Object Lock (WORM). The Bronze → Silver transformation applies pseudonymization (GST/phone replaced with UUIDs), outlier capping, schema normalization, and feature engineering via Apache Spark. No PII reaches the Silver layer or the model training pipeline.

Included Signals

What the Model Sees

  • Payment delay distributions (mean, P90, zero-delay rate)
  • Invoice frequency and GMV trajectory over time
  • Seasonal amplitude and recovery patterns
  • Return rate percentage and frequency
  • Distributor tenure and relationship breadth
  • Partial payment frequency and partial payment ratio
  • Order gap duration and regularity
  • Data completeness score for the retailer
Excluded Signals

What the Model Does Not See

  • Name, address, caste, religion, gender, age
  • GST number, phone number (pseudonymized)
  • Geographic location beyond state-level (binned)
  • Social media or web-derived behavioral signals
  • Bank account balances or external credit bureau scores
  • Any data collected without explicit retailer consent
  • Data from retailers who have revoked consent

Training / Validation / Test Split

SplitCompositionSizePurpose
Training Historical retailers with ≥12mo history + known outcomes 70% Parameter fitting
Validation Time-stratified holdout (most recent 6 months) 15% Hyperparameter tuning, early stopping
Test (OOT) Out-of-time: retailers onboarded after training cutoff 15% Final unbiased performance assessment

The out-of-time (OOT) test split is critical for credit models: using a temporal holdout prevents look-ahead bias that would inflate AUROC estimates. All reported metrics are OOT unless otherwise noted.

04 —

Feature Engineering

The model uses 40+ engineered features grouped into five families. Features are computed in the Silver layer via dbt transformations applied over Apache Spark. All features are deterministic — the same input data always produces the same features, facilitating auditability and reproducibility.

Family 1: Payment Behavior
Core creditworthiness signal · ~35% model weight (SHAP aggregate)
avg_payment_delay_daysMean days between invoice due date and payment receipt
p90_payment_delay_days90th percentile delay — captures tail behavior, not just average
zero_delay_rateFraction of invoices paid on or before due date
partial_payment_freqFraction of invoices that received partial (not full) payment
partial_payment_ratioMedian partial payment as % of invoice value
max_consecutive_delaysLongest streak of consecutive delayed invoices
Family 2: Order Consistency
Operational regularity signal · ~20% model weight
monthly_order_frequencyAverage orders per month over trailing 6 months
order_gap_median_daysMedian days between consecutive orders
order_gap_cvCoefficient of variation of inter-order gaps (regularity proxy)
return_rate_pctPercentage of invoiced items returned across all orders
return_freq_pctFraction of orders that had any return
gmv_per_order_cvVolatility of basket size (consistency proxy)
Family 3: Business Trajectory
Growth and viability signal · ~25% model weight
gmv_trend_slopeOLS slope of monthly GMV over trailing 12 months
gmv_3m_vs_12m_ratioRecent 3-month GMV vs. trailing 12-month average (acceleration)
gmv_yoy_growthYear-over-year GMV growth rate
active_months_pct% of months with at least one order (activity density)
invoice_count_trendOLS slope of monthly invoice count
avg_monthly_gmvMean monthly GMV (absolute scale, log-transformed)
Family 4: Seasonal Pattern
Temporal resilience signal · ~10% model weight
seasonal_amplitudeRatio of peak-season to trough-season GMV (Diwali/Eid/harvest windows)
seasonal_recovery_rateSpeed and completeness of GMV recovery after a seasonal trough
festival_spike_countNumber of distinct festival-window order spikes in training window
off_season_payment_delayPayment delay differential in off-season vs. peak (stress signal)
croston_demand_rate[Sparse retailers] Croston's adjusted demand rate for intermittent orderers
inter_demand_cv[Sparse retailers] Variation in non-zero demand periods
Family 5: Relationship Depth
Trust and context signal · ~10% model weight
distributor_tenure_monthsMonths since first invoice with this distributor
distributor_countNumber of distinct distributors in retailer's transaction history
credit_term_utilizationActual payment days vs. agreed credit terms ratio
dispute_rateFraction of invoices with recorded dispute/deduction
data_completeness_scoreWeighted completeness of retailer's data record (0–100)
data_freshness_daysDays since most recent ERP record (staleness signal)
Proxy Feature Notice

All features are reviewed quarterly for potential demographic proxy correlation. Features such as seasonal_amplitude and festival_spike_count are monitored for differential impact across religious community proxies. See Fairness section (06). No features encode geographic granularity below state level.

05 —

Model Performance

All performance metrics are computed on the out-of-time (OOT) test split. This is the only acceptable evaluation methodology for credit scoring models where look-ahead bias would render in-sample metrics misleading. Minimum thresholds below represent production promotion gates — a model that fails any threshold is returned to experimentation.

≥ 0.72 AUROC Area Under ROC — discriminatory power
≥ 0.35 KS Statistic Kolmogorov-Smirnov separation
± 2% PD Calibration Predicted vs. actual default rate delta
≥ 70% Lender Acceptance NBFC partner adoption rate

Score Band Performance Thresholds

Band Score Range Risk Label Expected PD Range Monotonicity Requirement Typical Recommended Limit
A 750–900 Low Risk < 5% PD(A) < PD(B) — enforced in test suite Up to 30% of 6-month GMV
B 600–749 Medium-Low Risk 5–12% PD(B) < PD(C) — enforced in test suite 15–25% of 6-month GMV
C 450–599 Medium-High Risk 12–25% PD(C) < PD(D) — enforced in test suite 10–15% of 6-month GMV
D 300–449 High Risk > 25% Highest PD cohort — enforced in test suite Decline or <₹25K conservative

Ongoing Monitoring Metrics

Metric Frequency Green Threshold Amber Threshold Red — Action Required
Population Stability Index (PSI) Monthly < 0.10 0.10 – 0.20 > 0.20 → Model refresh triggered
KS Statistic Monthly (when outcomes available) ≥ 0.35 0.25 – 0.35 < 0.25 → Champion/challenger triggered
PD Calibration Divergence Quarterly Within ±2% ±2–5% > ±5% → Model freeze, re-calibration
Score Distribution Shift Monthly P50 within ±30 pts of baseline ±30–60 pts > ±60 pts → Investigation required
Reason Code Coverage Daily 100% < 100% → Score blocked (RBI FLDG)
06 —

Fairness & Bias Analysis

AltScore commits to the 80% Rule (Adverse Impact Ratio ≥ 0.80) across all tested demographic and geographic cohorts. A model that fails fairness thresholds is frozen for affected cohorts until the disparity is remediated. Fairness is not optional — it is a production gate.

Guardrail GR-1 · Fairness & Bias Detection

Fairness Methodology

Since the model does not directly observe demographic attributes (by design — see Features, Section 04), fairness analysis uses indirect proxies available in the data: geographic region (state-level), retailer category (pharmacy, kirana, general merchant), and distributor affiliation as a proxy for supply-chain community. Analyses are performed quarterly by an independent reviewer on a pseudonymized dataset.

Adverse Impact Ratio (AIR) by Cohort — Target Thresholds

AIR = Approval rate of group ÷ Approval rate of most-favored group. Minimum acceptable: 0.80 (80% Rule). Values shown are design targets; actual monitoring occurs against live scoring data.

Urban vs. Rural Retailers
Target: ≥0.80
North vs. South India
Target: ≥0.80
Small Kirana vs. Pharmacy
Target: ≥0.80
Seasonal vs. Year-Round
Target: ≥0.80
Single-Distributor Retailers
Watch: 0.75–0.80
⚠ Single-distributor retailers are a known at-risk cohort. Conservative limit cap (50% reduction) applied when AIR approaches threshold.

Score Gap Analysis

For matched cohorts (retailers with similar GMV, tenure, and payment history), score gaps should not exceed 15 percentage points across any demographic-proxy cohort. Statistically significant disparities (p < 0.05 by Mann-Whitney U) trigger immediate review.

Bias Monitoring Controls

ControlImplementationFrequency
Feature proxy audit Correlation analysis of all features against demographic proxies Quarterly
Disparate impact reporting AIR computed for 8+ cohort groupings, reported to Guardrail Committee Quarterly
SHAP-based explanation audit Distribution of reason codes across cohorts checked for anomalous concentrations Monthly
Model freeze protocol Affected cohort frozen from scoring if AIR < 0.80; DPO + Board notified if >1,000 affected retailers Triggered
Independent fairness reviewer External audit of quarterly fairness report before board sign-off Annually
07 —

Known Limitations

Honest disclosure of model limitations is required under both the DPDP Act 2023 and RBI FLDG Guidelines, and is fundamental to responsible AI deployment in credit. Each limitation below is paired with its operational mitigation.

LIM-01 · Cold Start
Retailers with < 6 Months of Transaction History

The XGBoost primary model requires a minimum 6-month transaction window to produce a reliable payment delay distribution and trend signal. Retailers below this threshold cannot be scored using the primary model. A conservative rule-based fallback provides a provisional score capped at ₹25,000 with a low_confidence flag.

Mitigation: Cold-start fallback scoring + conservative limit cap + low_confidence flag in API response + lender notified via reason code DATA_INSUFFICIENT.
LIM-02 · Single Distributor
Retailers with Only One Distributor Relationship

Retailers who source exclusively from one distributor are more susceptible to biased scores if that distributor has data quality issues or if the relationship is atypical. The model cannot cross-validate behavior against a second distributor signal. This cohort also shows depressed AIR (see Section 06).

Mitigation: 50% limit cap applied automatically; single-distributor flag in API response; AIR monitoring with threshold alert at 0.77.
LIM-03 · Sparse / Seasonal Retailers
Retailers with Intermittent or Highly Seasonal Order Patterns

Standard payment delay and order frequency features lose predictive power for retailers who order infrequently or only during festival seasons (e.g., Diwali-only buyers). The primary XGBoost model is replaced by the Croston's Method routing for these retailers, but this sub-model has a smaller training sample and lower confidence estimates.

Mitigation: Automatic routing to Croston's sub-model; wider PD confidence intervals; seasonal adjustment window uses peak 6-month period rather than trailing 6 months.
LIM-04 · Training Data Recency
Model Trained Before Economic Shocks or Category Disruptions

The model's repayment outcome labels are derived from historical lending under the economic conditions prevailing during training. A significant economic shock (pandemic, commodity spike, supply-chain disruption) may cause the model's PD estimates to diverge from actual default rates faster than the monthly monitoring cycle can detect.

Mitigation: Monthly PSI monitoring with >0.20 threshold triggering model refresh; quarterly PD calibration check; NBFC partners advised to apply portfolio-level stress adjustments during macro stress events.
LIM-05 · Gaming Vulnerability
Coordinated Score Manipulation by Distributor-Retailer Collusion

A distributor who is aware of the model's feature logic could, in theory, systematically manipulate invoice timing or payment recording to inflate retailer scores. The Isolation Forest anomaly detector addresses isolated gaming attempts but may not detect highly sophisticated long-horizon coordination.

Mitigation: Isolation Forest with 60-day look-back; 70:30 long/short-term payment weight (long history dominates); cross-distributor behavioral consistency checks; distributor quarantine protocol for confirmed manipulation.
LIM-06 · Data Freshness Dependency
Score Accuracy Degrades with Stale ERP Data

AltScore scores reflect the retailer's behavior up to the most recent ERP sync. If ERP data is more than 14 days old, the score may not reflect recent payment behavior changes (positive or negative). This is especially relevant for retailers in financial stress who may have recently deteriorated.

Mitigation: data_freshness_days field returned in every API response; >7 days triggers warning in API response; >14 days adds low_confidence flag; >30 days blocks scoring entirely.
LIM-07 · Geographic Training Coverage
Underrepresentation of Certain States in Training Data

Phase 01 and 02 distributor onboarding is concentrated in Maharashtra, Karnataka, Tamil Nadu, and Delhi NCR. Retailers in Northeast India, tribal regions, or states with lower formal FMCG distribution penetration may be underrepresented in training data, potentially reducing model accuracy for those cohorts.

Mitigation: Geographic coverage tracked in quarterly fairness report; state-level AIR monitored; under-represented states flagged for additional data collection in Phase 03 expansion.
08 —

Intended & Prohibited Uses

The AltScore Credit Scoring Engine is purpose-built for a specific, constrained use case. Deployment outside these boundaries is not authorized, and AltScore Technologies bears no liability for misuse of model outputs beyond intended scope.

Permitted Uses

Working Capital Credit Underwriting — Informal Indian Retailers

NBFC partners using AltScore scores to make lending decisions for retailers within the agreed target segment (B2B informal retail, India, distributor-relationship verified, retailer consent obtained).

Credit Limit Sizing Guidance

Using the recommended_limit field (capped at 30% of trailing 6-month GMV) as an input into lender's own credit committee decisions. Lenders may set lower limits but may not exceed the AltScore ceiling without documented override.

Grievance-Driven Score Explanation

Providing SHAP-derived reason codes to retailers who request an explanation of their AltScore, via the WhatsApp grievance portal or distributor dashboard, in accordance with RBI FLDG Guidelines and DPDP Act rights.

Shadow Mode Pilot Evaluation

Running AltScore in parallel with existing lender credit processes for benchmarking purposes during Phase 02 shadow mode (≥30 days required before live lending use).


Prohibited Uses

Consumer Credit Underwriting

AltScore scores are derived from B2B distributor transaction behavior and are not validated for consumer (personal) credit decisions. Using these scores for personal loans, consumer durables, or mortgages is prohibited.

Insurance Underwriting

Insurance risk is a materially different actuarial problem. Using AltScore outputs as an input to insurance premium pricing or policy approval is not authorized without a new model validation exercise.

Demographic or Community Profiling

Using AltScore scores, reason codes, or underlying features to infer demographic characteristics, religious affiliation, caste, or community identity of retailers is strictly prohibited. Scores reflect only transactional behavior.

Non-Consented Retailers

Scoring any retailer who has not provided unambiguous, DPDP-compliant affirmative consent is prohibited. The system enforces this at the API level; any attempt to score a non-consented retailer returns a 403 error.

Model Output Resale to Third Parties

NBFC partners may not resell, sublicense, or otherwise transfer AltScore values or reason codes to any third party not named in the original retailer consent. Each lender is individually named in the consent scope.

Fully Automated Adverse Decisions Without Human Review

For Band D scores (High Risk) or when low_confidence: true is returned, a human credit officer must review the decision before loan decline is communicated to the retailer. Fully automated adverse decisions without human-in-the-loop violate DPDP Act automated decision-making provisions.

Consent Enforcement

The AltScore API enforces all use restrictions programmatically. Attempting to score a retailer without valid consent, to access scores cross-lender, or to exceed rate limits results in 4xx error responses. Technical enforcement does not substitute for contractual compliance — NBFC partners are required to maintain their own controls under the Partner Agreement.

09 —

Explainability & Reason Codes

Every AltScore response includes a mandatory set of SHAP-derived reason codes explaining the key drivers of the score. This is a hard system requirement — scores without reason codes are blocked and not returned to lenders. This design ensures compliance with RBI FLDG Guidelines and the DPDP Act's right to explanation.

Positive Drivers (Score Boosters)

What Raises the AltScore

  • CONSISTENT_ORDER_FREQ — नियमित ऑर्डर पैटर्न
  • LOW_PAYMENT_DELAY — समय पर भुगतान
  • GROWING_BASKET_SIZE — बढ़ता कारोबार
  • LOW_RETURN_RATE — कम वापसी दर
  • LONG_DISTRIBUTOR_TENURE — लंबे समय का व्यावसायिक संबंध
  • STRONG_GMV_TREND — मजबूत बिक्री वृद्धि
  • ZERO_DELAY_RATE_HIGH — समय पर भुगतान का उच्च अनुपात
  • SEASONAL_RECOVERY — त्योहार के बाद वापसी
Negative Drivers (Score Reducers)

What Lowers the AltScore

  • PAYMENT_DELAY_HIGH — उच्च भुगतान विलंब
  • P90_DELAY_GT_15DAYS — अधिकतम देरी 15 दिन से ज़्यादा
  • DECLINING_GMV — घटता कारोबार
  • HIGH_RETURN_RATE — उच्च वापसी दर
  • ORDER_GAP_DETECTED — ऑर्डर में लंबा अंतराल
  • PARTIAL_PAYMENT_FREQ — आंशिक भुगतान बहुत बार
  • SEASONAL_GAP_DEEP — त्योहार के बाद कोई वापसी नहीं
  • DATA_INSUFFICIENT — पर्याप्त डेटा नहीं

Reason Code Generation Rules

RuleRequirementEnforcement
Minimum codes per response ≥ 5 reason codes (≥3 positive, ≥2 negative) Hard block — score not returned if <5 codes generated
SHAP coverage 100% of scored retailers must have SHAP values computed Daily monitoring; <100% triggers alert
Language support All 24 codes have verified Hindi translations Translation table versioned in code repository
Code taxonomy stability Reason codes are stable across model versions New codes require Guardrail Committee sign-off + lender notification
Adverse action reason codes Band D decisions and limit reductions must surface top 3 negative codes Enforced in API response serialization

Retailer-Facing Explanation

Retailers may request an explanation of their score via the WhatsApp grievance portal at any time. The explanation is rendered in plain Hindi using the reason code translations and is reviewed by a human credit officer within 24 hours of request. Retailers are not shown raw SHAP values or feature weights — only the categorical reason code descriptions.

SHAP Opacity Notice

Actual SHAP numeric values and feature weights are not exposed to retailers, lenders, or distributors via the API. This is intentional: exposing numeric weights would enable sophisticated gaming of the model's scoring logic. Reason codes convey the directional signal without exposing the precise decision boundary.

10 —

Model Lifecycle & Regulatory Alignment

Model Update Cadence

The AltScore engine follows a structured champion/challenger model lifecycle. The in-production champion model is continuously monitored via PSI, KS, and PD calibration metrics. When thresholds are breached, a challenger model is trained and validated before promotion.

Stage 1 — Development
Training & Validation

Challenger model trained on refreshed data. OOT test split evaluated. Fairness analysis performed. All metrics must exceed promotion gates (AUROC ≥0.72, KS ≥0.35, AIR ≥0.80).

Stage 2 — Shadow Mode
Minimum 30-Day Parallel Run

Challenger scores computed alongside champion but not used for lending decisions. Rank-order accuracy vs. champion must reach ≥75% concordance before promotion is even considered.

Stage 3 — Promotion Gate
Two-Person Sign-Off Required

Head of Risk + CTO (or delegate) must both approve promotion. Model artifact SHA-256 hash recorded in immutable audit log. NBFC partners notified of model version change with 72-hour advance notice.

Stage 4 — Production
Champion Scoring with Continuous Monitoring

Monthly PSI and score distribution monitoring. Quarterly KS and fairness audit. Drift detection triggers return to Stage 1 or emergency rollback.

Stage 5 — Rollback
<10 Minute Rollback Capability

Previous champion model version retained in WORM storage with hash verification. Rollback restores previous model artifact and all routing configuration. No re-training required for rollback.

Regulatory Alignment Map

RBI FLDG Mandatory reason codes on every score; lender-readable categorical explanation; adverse action disclosure with top-3 negative codes ✓ MET
DPDP Act 2023 Automated decision-making transparency; right to explanation; human review for adverse decisions; consent-gated scoring; right to grievance ✓ MET
Fair Lending Adverse Impact Ratio ≥0.80 enforced; quarterly fairness audit; model freeze for AIR breach; no protected class proxies in features ✓ MET
SOC 2 Type II Model artifact integrity (SHA-256 + WORM); access controls on ML pipeline; audit trail for model promotions; availability monitoring ◎ Month 12
ISO 27001 Information security management for ML pipeline; key management for model artifacts; supplier risk for ML libraries ◎ Month 18
RBI AA Framework Integration with Account Aggregator for bank statement enrichment; consent framework alignment with AA consent artefact standard ◎ v2 Roadmap

Model Card Update Cadence

TriggerRequired UpdateOwner
New model version promoted to production Full card refresh — all sections ML Engineering + Credit Risk
New feature family added Section 04 (Features) updated; fairness analysis re-run ML Engineering
Fairness audit finds new at-risk cohort Section 06 updated; limitation added to Section 07 Head of Risk + DPO
Regulatory change Section 10 compliance map updated; legal review Legal & DPO
Annual review (minimum) All sections reviewed; sign-off from ML Lead + Head of Risk + DPO Cross-functional
Document Sign-Off

MC-ALTSCORE-001 v1.0

  • ML Engineering Lead — Model accuracy, features, lifecycle
  • Head of Credit Risk — Thresholds, intended use, limitations
  • Data Protection Officer — Fairness, DPDP compliance, privacy
  • Head of Product — Use case scope, prohibited uses
  • CISO (observer) — Security controls, model integrity
Distribution List

Confidential Disclosure

  • Active NBFC lending partners (on execution of Partner Agreement)
  • RBI Regulatory Filings (on request)
  • DPDP Board (on regulatory inquiry)
  • Internal: ML, Risk, Legal, Product, Engineering leadership
  • External audit / SOC 2 auditors (redacted version)