Credit Underwriting Agent AI

Invoked when: application submitted to the loan origination system with a complete or near-complete document set

• –Applies the current credit policy scorecard — retrieved via RAG at invocation time, always the live version — to the application data: bureau score against the segment cut-off, FOIR (Fixed Obligation to Income Ratio) computed from verified income and declared obligations, LTV (Loan to Value) computed from declared or assessed collateral, leverage ratio for MSME borrowers, and sector exposure check against portfolio concentration limits.
• –Computes each scorecard parameter from the verified data, not the declared data — if the GST-verified turnover is lower than the stated turnover, the FOIR is computed on the GST figure. If the bank statement cash flow is lower than the ITR income, it flags the discrepancy and computes both versions, presenting both to the decision output so the human reviewer understands the spread.
• –Applies hard filters first — a borrower who is below the bureau cut-off or above the sector exposure limit gets a hard decline regardless of other scorecard dimensions. These are non-negotiable policy boundaries. The agent does not override hard filters, does not recommend exceptions to hard filters, and does not present arguments for why a hard-filter decline might be revisited.
• –Produces a scorecard summary that shows the applicant's position on every parameter — not just pass/fail, but the actual figure against the limit, so the human reviewer can immediately see which parameters are strong, which are marginal, and which are failing, without recalculating anything themselves.

Invoked when: bureau report is retrieved as part of the application processing flow

• –Reads the full bureau report — not just the summary score — including the tradeline detail: every credit facility, its current status, payment history (DPD by month), outstanding balance, sanctioned amount, and the lender name. The summary score is a starting point; the tradeline tells the story the score does not.
• –Identifies bureau signals that the score alone does not capture: a borrower with a 720 score who has a single large DPD-60 on a secured loan 18 months ago is materially different from a 720-score borrower with a clean tradeline — the score is the same, the risk profile is not. The agent narrates what the tradeline means for this specific application.
• –Flags bureau-specific red signals regardless of score: a loan that was written off or settled (even if the score has partially recovered), a borrower who appears on multiple bureau reports under slightly different names or addresses (identity risk), or a tradeline that shows a new unsecured loan taken within the last 90 days that was not declared in the application (undisclosed liability).
• –For thin-file borrowers — those with limited or no bureau history — does not invent a risk assessment. It states explicitly that the bureau signal is insufficient for score-based decisioning, flags the case as requiring alternate data or L2 human review, and lists the additional information that would be needed to make a decision. A thin file is not a clean file; it is an unknown file.

Invoked when: thin-file borrower, bureau signal is inconclusive, or stated financials require independent verification via alternate data sources

• –Reads the alternate data signals available at invocation — Account Aggregator bank statement data (12-month cash flow, average monthly balance, income credits, EMI debits, bounce frequency), GST filing data (turnover, filing regularity, GST-to-income ratio), and ITR data (declared income, ITR filing history, tax paid vs income claimed) — and synthesises them into a financial health picture that either corroborates or contradicts the stated application data.
• –Applies a specific corroboration logic: for an MSME borrower claiming ₹50 lakh annual turnover, the agent checks whether the bank credits over 12 months are consistent with that claim, whether the GST-declared turnover is within a reasonable range of the bank credit figure, and whether the ITR income is consistent with both. Where all three corroborate, the confidence is high. Where they diverge, it states the specific figures and the direction of divergence.
• –Weights alt data signals differently by source reliability: bank statement data from an Account Aggregator pull is higher reliability than a self-submitted bank statement PDF because it cannot be tampered with. GST data from the GSTN API is authoritative. ITR data via AIS (Annual Information Statement) is authoritative. Self-submitted documents require manual verification before they can be treated as reliable inputs.
• –Does not use alt data to override a hard bureau filter. If the bureau score is below the hard cut-off, alt data showing strong cash flow is presented as contextual information for a potential exception review — it does not automatically lift the case above the cut-off. Policy exceptions require human authority regardless of how strong the alternate data is.

Invoked when: scorecard, bureau interpretation, and alt data integration are complete and a final verdict is required

• –Synthesises the scorecard result, bureau interpretation, and alt data picture into a single structured credit verdict: Approve (within policy, autonomous), Refer to L2 (within policy but with flags or thin data requiring human review), Refer to L3 (policy exception or high-risk indicator requiring senior credit officer), or Decline (hard filter triggered or risk profile outside policy parameters).
• –Produces a plain-language explanation of the verdict designed for two audiences simultaneously: the credit officer (who needs the technical basis — which policy parameter, which data point, which bureau finding drove the decision) and the borrower (who needs a non-technical statement of the reason if the application is declined or conditioned, as required by RBI's guidelines on transparency in algorithmic lending).
• –For approved applications: states the approval conditions — any documentation still required before disbursement, any covenants or monitoring requirements attached to the approval, and the expiry date of the approval if the borrower does not proceed within the validity period.
• –For declined applications: states the specific reason — not a generic "does not meet credit criteria" but the specific parameter that failed (e.g., "FOIR of 58% exceeds the policy limit of 50% for this product segment based on GST-verified income of ₹X") — because this is the explanation the borrower is entitled to under RBI guidelines and the one the credit officer must be able to stand behind if questioned.