How to Build a Risk Provisioning Agent for a Lending Institution

What is a Risk Provisioning Agent?

A Risk Provisioning Agent is an AI agent that automates loan asset classification under IRACP norms, calculates provision requirements at the account and portfolio level, and produces audit-ready provisioning schedules for board and regulator review.

The core tasks it replaces are: pulling repayment records to compute DPD, mapping each account to its correct NPA category, applying the applicable provision rate from the institution's policy, aggregating to a portfolio-level provision requirement, and producing the schedule in the format required for board packs, statutory audit, and RBI inspection. What takes a risk team four to six working days per quarter can be reduced to under an hour of supervised run time.

Why is IRACP the non-negotiable foundation?

IRACP — Income Recognition, Asset Classification, and Provisioning — is the RBI framework that governs how banks and NBFCs classify loan assets and calculate minimum provisions. Any AI provisioning agent deployed in India must implement IRACP classification logic correctly as its base layer; nothing else can substitute for it in a regulated environment.

The IRACP asset classification hierarchy is as follows:

The agent must know these rates as a base floor — not targets. The institution's internal provisioning policy may stipulate higher rates than the IRACP minimum, and the agent must always apply whichever is more conservative.

How does DPD logic drive NPA classification?

DPD — Days Past Due — is the number of calendar days since a scheduled repayment obligation (principal, interest, or instalment) was missed. It is the primary trigger variable for IRACP classification, and computing it correctly is the most operationally sensitive part of building a provisioning agent.

Three DPD computation rules the agent must implement precisely:

1. DPD is account-level, not transaction-level. If a borrower misses a partial payment, the DPD clock starts from the original due date of the overdue amount — not the date of the partial payment. An agent that restarts the DPD clock on partial receipt will systematically under-classify accounts.
2. Upgrades require a clean repayment period. An account cannot move from NPA back to Standard simply by clearing arrears once. IRACP requires a sustained period of satisfactory repayment — typically one year for Sub-Standard accounts — before an upgrade is permitted. The agent must track the upgrade clock separately from the DPD clock.
3. The DPD anchor date must be consistent across the portfolio. Whether you use the CBS end-of-day date or a fixed monthly cut-off, it must be the same for every account in a given provisioning run. Inconsistency in the anchor date produces classification differences for accounts with due dates near the cut-off — a common audit finding in manual processes.

When and how should you layer in IFRS-9 ECL?

IFRS-9 ECL (Expected Credit Loss) should be layered on top of IRACP classification, not substituted for it. IRACP compliance is mandatory for RBI reporting; IFRS-9 alignment is additionally required for institutions with international investors, overseas borrowings, listed instruments, or group-level reporting obligations under Ind AS.

The IFRS-9 staging logic maps approximately — but not identically — to IRACP classification:

The practical implication for the provisioning agent: IRACP classification must be computed first, and the IFRS-9 stage is then derived from it — with one important difference. IFRS-9 Stage 2 can be triggered by qualitative signals (significant deterioration in borrower risk profile, macro sector stress, covenant breach) even before DPD reaches 31 days. The agent must be able to receive qualitative risk flags from the Early Warning System and incorporate them into stage assignment, not rely on DPD alone.

What data does a Risk Provisioning Agent need?

Four data feeds are required at invocation. All of them should be injected as structured files — the agent should not pull from live systems autonomously.

1. Loan-level repayment ledger: Account ID, scheduled due dates, actual payment dates, amounts paid vs. billed, NACH return codes where applicable. This is the primary input for DPD computation. It must be extracted at a fixed cut-off date and version-locked for the provisioning run.
2. Outstanding balance and security register: Current principal outstanding, accrued interest, collateral type, and estimated realisable security value per account. Required for applying the secured/unsecured bifurcation in Doubtful-category provision rates.
3. Provisioning policy document: The institution's current provisioning policy — IRACP minimum rates, any internal overlay rates, specific rules for product categories (e.g., gold loan, MSME, agri), and the write-off and upgrade criteria. This should be loaded via RAG at invocation so the agent always applies the current approved policy, not a cached version.
4. Prior-period NPA register: The NPA classification from the previous provisioning cycle. Required for tracking upgrade and downgrade movements, computing net NPA accretion, and producing the period-on-period comparison table that statutory auditors and RBI inspectors always request.

How should the provisioning agent outputs be designed?

A provisioning agent that only produces a provision number is half-built. The outputs need to serve four distinct consumers: the risk team (verification), the CFO (P&L impact), the board (governance visibility), and the auditor / regulator (audit trail).

What hard guardrails must a Risk Provisioning Agent have?

Provisioning agents operate on data that directly affects the institution's published financial statements. The guardrails are correspondingly strict.

• Will not classify or reclassify accounts without a complete repayment ledger. If the data for an account is missing or inconsistent, the agent flags it as an exception — it does not estimate or interpolate a classification.
• Will not apply provision rates below the IRACP minimum. Even if the institution's internal policy contains a rate that appears to be below the regulatory floor, the agent must apply the higher of the two and flag the policy conflict for review.
• Will not approve provision releases or write-offs. Reducing a previously held provision is an accounting decision with P&L impact. It requires CFO and audit committee sign-off — the agent can recommend and document, but cannot execute.
• Will not produce outputs from a prior-period data set without flagging the vintage. Every provisioning output must be clearly stamped with the data cut-off date it was computed from. Undated provisioning schedules are an audit risk.
• Will not retain loan-level data between sessions. Account-level repayment and balance data is sensitive financial information. Session-scoped memory is the only compliant default.

What does the human governance layer look like?

A well-designed provisioning agent reduces the human workload from days to hours — but it does not eliminate the human decision points. There are four that cannot be automated away.

1. Exception resolution. Every account on the exception list requires a human decision before the schedule is finalised. The risk team reviews exceptions, applies judgment, and documents the rationale. The agent provides the exception list and the data behind each flag; the human provides the decision.
2. Policy override documentation. Where the institution applies a provision rate higher than the IRACP minimum — or where a management overlay is applied to a segment — the rationale must be documented and approved by the risk head. The agent surfaces where overrides exist; the risk head signs off on them.
3. Board and audit committee review. The portfolio provision summary and NPA movement schedule go to the board risk committee and audit committee for review and approval before the figures are incorporated into financial statements. The agent produces board-ready outputs; the board approves them.
4. Regulatory submission sign-off. Any provision data submitted to RBI — whether in an NBS return, an ICAAP filing, or an inspection response — must be signed off by the CFO or authorised officer. The agent produces the data; the signatory certifies it.

Frequently Asked Questions