Built for India's AI Governance Reality

When a credit scoring model produces a rejection signal, what exists at that moment is a numerical output — a probability of default, a risk score, a binary classification — and a decision boundary that the applicant's profile has failed to cross. The model has done its work. What has not yet happened is governance. The score is not a reason. The decision boundary is not an explanation. And under the RBI's Digital Lending Guidelines and the Fair Practices Code applicable to NBFCs, what a lender is required to communicate to the applicant is not a score but a grounds-of-rejection — a statement, in language accessible to the applicant, of why the credit was not extended. NomoCrit intercepts the decision signal at this moment, before it propagates to the applicant-facing layer, and initiates the governance workflow that produces what the regulation actually requires.

The grounds-of-rejection artifact is not a SHAP value report. SHAP values are model-internal quantities — they measure the marginal contribution of each feature to a prediction relative to a baseline, and they are technically precise in a way that is entirely inaccessible to an applicant who did not train the model. NomoCrit's explainability layer performs a translation: from feature-level SHAP contributions, mapped against the lender's configured feature taxonomy, into a structured set of rejection grounds that correspond to the categories recognised in the Fair Practices Code — income adequacy, repayment history, existing obligations, credit utilisation, and similar. The translation is not a simplification; it is a legally relevant rendering of the model's actual decision basis, structured to satisfy both the RBI Digital Lending Guidelines' communication requirement and the evidentiary standard that would apply if the decision were contested. Each ground is generated with a confidence boundary that allows the artifact to acknowledge the relative weight of each contributing factor without misrepresenting the model's internal precision.

Under the RBI's Digital Lending Guidelines, the lender is required to communicate the rejection grounds to the applicant within the timeframe specified under the Guidelines — as part of the loan sanction or rejection letter. NomoCrit's delivery infrastructure passes the structured artifact to the lender's customer communication layer in a format configured for the lender's regulatory profile — digital channels where the Guidelines permit, physical correspondence where required. The artifact received by the applicant contains a human-readable statement of the grounds, a reference number tied to the decision log, and, where the lender has enabled recourse infrastructure, a description of the appeal pathway available and the steps required to initiate it.

The appeal pathway, when invoked, does not route to an unstructured inbox. NomoCrit's recourse infrastructure logs the appeal against the original decision record, timestamps it, and routes it to the lender's designated review function according to the escalation logic configured by the lender's compliance team. Every interaction in the appeal process is appended to the decision record as a governance event. When the lender's review function issues a response, that response is logged with the same structure as the original decision artifact. The result is a complete, reconstructable trail from the original application through the model decision, the grounds communication, the appeal submission, and the lender's response — a trail that satisfies the grievance redressal requirements of the Fair Practices Code and the data principal rights provisions of the Digital Personal Data Protection Act, without requiring any manual reconstruction after the fact.

A model risk management review by an RBI examiner typically proceeds from a set of questions that are standard in form but require non-trivial infrastructure to answer with precision. What models are in production? What training data was used, and over what period? What is the model's current performance on a representative test population, and how has that performance changed since deployment? Are there segments of the lending population for which the model produces materially different approval rates, and what is the lender's analysis of whether those differences are justified by credit risk differentials or represent disparate impact? What is the decision log — the record of individual model outputs — and is it available for examination? Lenders who have not instrumented their AI stack to produce these answers as operational outputs face the same problem at each question: the answer exists somewhere in the organisation, in some combination of data warehouses, model repositories, and manual records, but it does not exist as a coherent, examination-ready artefact.

NomoCrit maintains a decision ledger as a primary operational output, not a secondary reporting layer. Every credit decision processed through the governance stack generates a ledger entry containing: the decision timestamp, the model version in production at that moment, the input feature vector (within the scope of data retention obligations under the DPDP Act), the SHAP contribution array, the threshold applied and its calibration date, the decision output, the fairness metrics computed for that decision's population segment, and the artifact reference for the grounds of rejection generated. The ledger is structured relationally — every entry is linked to the model version record, the threshold governance log, and, where applicable, the recourse record — so that an examiner can navigate from an individual decision to its full governance context without requiring manual cross-referencing.

The 72-hour audit export (target SLA for production deployments) is not a reporting feature; it is an architectural constraint that NomoCrit's data layer is designed to satisfy. When an examiner submits a formal request — specifying a decision population (date range, product type, geographic scope) or a model version under review — NomoCrit generates a structured export mapped to the FREE-AI principles checklist and the Digital Lending Guidelines compliance matrix. The export includes the aggregate fairness analysis across protected-attribute proxies for the requested population, the threshold governance history showing any recalibration events and the triggers that initiated them, and the model card for each model version active during the review period. The format is designed for examination: cross-referenced, complete, and self-consistent, without requiring the lender's technology team to prepare or curate the submission.

Without this infrastructure, the alternative is reconstruction — a process that is not simply slow but structurally unreliable. A lender asked to produce the decision basis for a specific rejection from eighteen months ago, where the model has since been retrained twice and the original feature pipeline has been modified, faces a reconstruction problem that may have no complete solution. The decision was made; the model that made it may no longer exist in production form; the feature values at the time of decision may not have been stored; and the fairness analysis of the relevant cohort requires access to a population that has changed. The evidentiary gap this creates — between what the examiner asks for and what the lender can produce — is precisely the gap that FREE-AI enforcement, as it matures, will treat as non-compliance. NomoCrit's position is that this gap should not be resolved retroactively. It should not exist.

Model drift in lending AI does not present as a system failure. There is no error message, no declined transaction, no observable discontinuity in the operational flow. What drift looks like, in the first weeks and months after it begins, is a gradual shift in metrics that individually fall within acceptable ranges: approval rates that move a few percentage points, average predicted risk scores that creep upward or downward across a sub-population, a fairness metric that degrades from 0.94 to 0.89 to 0.83 across successive monthly cohorts without crossing a defined alert threshold. The model is still producing outputs. The outputs are still being processed. The decisions being made are increasingly misaligned with the credit reality the model was trained to represent — because that reality has changed, and the model has not. In Indian credit markets, the proximate causes are not unusual: the post-monsoon seasonal shift in agricultural and rural borrower profiles, a change in bureau data formatting that alters the distribution of a key input feature, a rate cycle that restructures the repayment capacity calculations underlying existing obligations. None of these require a technical failure for the model to begin producing decisions that are both less accurate and less fair.

NomoCrit's adaptive threshold engine monitors four distinct drift signals in parallel. Population Stability Index across the primary input features identifies when the distribution of model inputs has shifted significantly from the training distribution — the standard PSI threshold (0.25 PSI, a standard model risk management threshold) indicates a critical shift requiring recalibration, and NomoCrit monitors at this sensitivity continuously rather than on a scheduled basis. Feature-level drift detection identifies which specific inputs are contributing to distribution shift, enabling the governance log to record not just that drift was detected but which features drove it. Fairness metric deviation tracks approval rate parity and equalised odds across the lender's configured demographic segments on a rolling cohort basis, and flags when any metric crosses a defined tolerance band. Approval rate shift by segment identifies when specific borrower segments are experiencing approval rate changes that exceed what the credit risk signal would justify — a leading indicator of fairness degradation before aggregate metrics reflect it. The latency between drift onset and detection is a function of monitoring frequency and cohort size; for most production deployments, NomoCrit's monitoring operates on daily cohort cycles.

When drift detection triggers at any of these signals, the response is structured by severity and type. Threshold recalibration events — where the drift is confined to the decision boundary's relationship to the feature space, without requiring model retraining — are initiated automatically, logged as governance events with the trigger condition, the prior threshold, the recalibrated threshold, and the cohort statistics that drove the change, and routed to the lender's model risk management function for review and ratification within a configurable window. Events that exceed the automatic recalibration scope — where the feature distribution shift is severe enough to require model retraining or where the fairness metric deviation cannot be resolved by threshold adjustment alone — generate a formal governance alert, suspend the affected threshold adjustment pending human review, and flag the model version as requiring validation before continued production use. Every event in this workflow is a governance record, immutable and timestamped, available in the audit export.

The lender without drift detection infrastructure does not experience the absence of these alerts. They experience the absence of the information those alerts would have conveyed — and that absence is invisible until the accumulation of drifted decisions reaches a scale where aggregate outcomes become anomalous. By that point, the fairness degradation is not a potential finding; it is an established pattern across a credit cohort. The approval rate differential that began as a 2% shift has compounded across six months of production decisions into a documented discriminatory outcome. The threshold misalignment that should have triggered recalibration in October has instead produced a quarter of miscalibrated decisions that must now be evaluated for remediation. When this pattern is discovered in an audit — and under FREE-AI supervision timelines, discovery is a matter of when, not if — the lender's position is not that they failed to monitor their model. It is that they produced discriminatory outcomes at scale and the governance infrastructure to detect and prevent them was not in place. That is a substantially different regulatory exposure than a calibration event that was detected, logged, and resolved within its monitoring cycle.