The RBI's Fair Practices Code requires lenders to give applicants reasons for rejection. The harder question is what "explain" means when an AI system assisted the assessment. A machine learning score is not an explanation. It is only a number, and regulators, credit committees, and borrowers increasingly want to know what supports it.
This is not mainly a model-interpretation problem. An interpretable model can help, but it is not the only answer and may not be the right one. The more useful test is whether the lender can record the data used, the queries run against it, the returned results, and how the analyst applied those results to reach a recommendation. That record is the audit trail. Without it, regulatory and internal governance risk remain.
What Credit Committees Need to Review
A committee reviewing an underwriting recommendation needs to establish that the recommendation is supported. In a manual review, it could ask the analyst to walk through the statements. The analyst would identify particular transactions, dates, and amounts. The evidence was visible and could be checked when required.
Automation does not remove that requirement. The committee still needs to know which data was queried, what came back, and which findings mattered. A recommendation without traceable evidence is difficult to defend if the loan defaults and the decision is examined later.
The preferred evidence format depends on the committee. It may be a structured summary with flagged metrics and transaction support, drill-down access to raw query results, or a narrative credit note with data citations. None of these formats is served by a score that shows no workings.
What the RBI Framework Requires Today
The RBI's Fair Practices Code requires lenders to communicate rejection reasons in writing. The obligation applies whether the assessment was manual or automated. An AI-assisted rejection therefore needs to state, in terms the borrower can understand, which factor in the financial profile led to the adverse assessment.
The Fair Practices Code is not the only relevant context. The RBI has also raised concerns about opaque algorithmic credit scoring through circulars and its wider discussion of digital lending guidelines. Although the current framework has no single explicit "AI explainability" requirement, lenders using automated assessment systems should be ready to explain their decisions and retain the records that support those explanations.
For a lender accessing financial information through the AA framework, the consent artifact records the scope of data authorised for an application. That is a useful starting point, but it is not a complete audit trail. Consent shows what could be accessed. It does not show which queries were executed or what they returned.
What a Complete Audit Trail Contains
A complete trail should preserve the following sequence for an AI-assisted credit decision:
Data source and consent: record the accounts queried, the consent artifact used, and the date range accessed. Where AA-sourced data is involved, log the consent ID and link it to the consent record held by the AA.
Queries run: record each query executed against the data, including the question, parameters such as date range, amount thresholds, and classification criteria, and the timestamp.
Query outputs: retain each returned result, whether a computed value, boolean, or list of qualifying transactions, together with the supporting transactions. A reviewer can then check that the query ran correctly and that the result represents the transaction history.
Analyst interpretation: record the analyst's conclusion, the findings treated as material, and the connection between those findings and the product's credit policy criteria.
Decision: retain the recommendation, whether approve, reject, refer, or hold, the proposed credit limits or terms, and the identity of the analyst and any approver.
Together, these records allow the decision to be reconstructed later. If a borrower disputes a rejection, the lender can produce the data evidence behind the cited factors. If internal audit examines approvals for portfolio quality, the evidence for each approval remains retrievable.
The Technical Design Consequence
An audit trail must be built into the credit query tool rather than added later. Each query needs its parameters logged, each result needs its supporting evidence rows stored, and the log needs to connect to the application record.
A system that keeps only a summary score or table cannot recreate a complete trail later if it discards the intermediate results and supporting transactions. The summary may be suitable for the analyst's screen, but the evidence beneath it must also be persisted.
This choice adds storage and logging work. That operational cost is modest beside the risk of being unable to explain a decision when asked. For lending operations expecting greater volume and regulatory scrutiny, recording the evidence at the outset costs less than adding it after decisions have already been made.
Explaining Rejections to Borrowers
Explaining a rejection is more than a compliance task. A borrower who receives a clear explanation tied to specific financial factors can understand what to address before reapplying. A generic "credit assessment" rejection offers no actionable information and gives the borrower no basis for judging whether the process was fair.
A query-level trail makes a borrower-facing explanation practical. Findings behind an adverse assessment, such as inconsistent income, recent NACH returns, or existing debit obligations that are high relative to inflow, can be expressed plainly with reference to the underlying evidence, without exposing raw transaction data improperly.
We are not saying that this is easy to implement well. We are saying that clear, fair, non-discriminatory rejection language becomes workable when findings are structured and retrievable. Templates still need careful design and validation to ensure they describe the findings accurately. Without structured evidence, the task is not workable.