The Credit Policy Is a Photograph; The Portfolio Is a Film.

It is the third week of the quarter. Defaults in your Near-Prime portfolio are beginning to rise. The credit team can see the trend, but the policy review is scheduled for next month.

So, the usual exercise begins: extract the portfolio tape, prepare pivots, debate CIBIL cut-offs and circulate a revised policy note. By the time the recommendation reaches the field, market conditions may have changed again.

This raises a fundamental question: Why should credit policy remain static when portfolio behaviour is continuously changing?

Ask yourself: “Why should a policy review take three months when the underlying portfolio can change in three weeks?”

Business Intelligence is not Decision Intelligence

This distinction deserves attention because the two are often used interchangeably. Business Intelligence tells us what has happened. It provides dashboards, portfolio trends, vintage analysis, segment performance and exception reports. It helps management understand the state of the portfolio.

Predictive Analytics takes this further by estimating what is likely to happen. It identifies emerging risks, predicts defaults and anticipates portfolio deterioration.

Decision Intelligence addresses a different question: Given what has happened and what is likely to happen, what should we do?

Consider a Near-Prime portfolio where defaults are increasing.

• BI identifies the deterioration and quantifies its extent.
• Predictive Analytics estimates the likely future default trajectory.
• Decision Intelligence evaluates alternative CIBIL cut-offs, FOIR limits and ticket sizes, quantifies their impact on profitability and risk, and identifies feasible policy configurations.

The difference is between reporting a problem, predicting its consequences and evaluating the available responses.

A dashboard can tell the credit committee that the portfolio is deteriorating. A predictive model can estimate how much worse it might become. But neither, by itself, tells the committee which policy intervention offers the best risk-return trade-off.

That is the role of Decision Intelligence.

BI improves visibility. Predictive Analytics improves anticipation. Decision Intelligence improves the quality of decisions.

From periodic reviews to continuous decision intelligence

“The uncomfortable possibility is not that machines will make every decision. It is that machines will expose how many of our decisions were never systematically evaluated in the first place.”

Historical data is essential. The problem is not the data, but the frequency with which we analyse it and translate the findings into policy.

Two limitations stand out.

1. Market conditions change faster than policy reviews. A policy calibrated to last year’s portfolio may no longer be appropriate today. Changes in borrower behaviour, economic conditions and segment-level risk can make existing thresholds ineffective.

2. Policy decisions are often based on limited alternatives. Committees typically debate a few proposed cut-offs. They rarely evaluate the complete risk-return trade-off. Consequently, it is difficult to establish how much profitability is being sacrificed for a marginal reduction in risk, or whether a better policy configuration exists.

The objective should be to move from periodic portfolio reporting to continuous evaluation of policy alternatives.

The capability staircase: but not necessarily a journey of years

Traditionally, lenders have progressed through several stages:

1. Excel and static extracts: Periodic portfolio snapshots and manual analysis.
2. Pivots and dashboards: Faster analysis and visibility into portfolio movements.
3. Predictive analytics and scorecards: Risk estimation, segmentation and borrower ranking.
4. Data engineering pipelines: Automated collection, processing and regular refresh of portfolio information.
5. Decision science and optimisation: Evaluation of alternative policy configurations against defined risk-return objectives.
6. Contextual and adaptive decisioning: Applicant-level decisions within approved policy boundaries, with feedback from subsequent outcomes.

However, this should not be interpreted as a mandatory, multi-year technology transformation. Today, cloud platforms, managed data services, APIs and AI-assisted development can significantly compress implementation timelines. Even a reasonably structured dataset can support a working optimisation prototype. One does not necessarily need a sophisticated enterprise data lake before demonstrating the value of decision science.

A dashboard tells us what has changed. Predictive analytics estimates what might happen. Decision science evaluates what we should do about it. That is the progression that matters.

Strengthening judgement, not replacing it

Humans continue to define risk appetite, approve policy changes and decide which trade-offs are acceptable.

What changes is the quality of information presented to the decision-makers: updated portfolio evidence, a wider set of alternatives and independently verified recommendations.

In my earlier article, I discussed why model ranking alone is insufficient for business decisions. This experiment takes the discussion one step further: given risk estimates and observed portfolio outcomes, how can a lender evaluate and govern alternative policy responses as market conditions change?

One clarification: this is primarily a decision-science and optimisation experiment, not an LLM demonstration.

The quantitative work is performed by four methods:

• Optuna TPE
• SLSQP
• NSGA-II
• LinUCB contextual bandit

The LLM acts as an orchestration layer. It interprets portfolio telemetry, selects analytical tools, coordinates execution and prepares recommendations for review. It does not calculate risk, perform optimisation or approve deployment.

I implemented a live Claude integration through the Anthropic API and retained a deterministic scripted planner as an alternative. Both were tested across three scenarios. In the single live Claude run, it selected the same tool sequence and produced the same figures as the scripted planner. This does not establish that every future run will behave identically.

The experiment uses 600 synthetic applicants across Prime, Near-Prime and Sub-Prime segments. It can run on a laptop or in a Databricks notebook in under ten seconds.

Point to ponder: If an optimisation engine can evaluate hundreds of policy configurations before the committee finishes discussing the first three, what exactly should the committee be spending its time on?

Understanding the experiment

Synthetic portfolio construction

CIBIL scores follow a normal distribution (mean 715, standard deviation 50), capped between 600 and 850. Monthly incomes follow a lognormal distribution, with a median of approximately Rs 55,000.

LGD is assumed to be 60%. Market stress increases default probabilities by 1.5x for Near-Prime and 1.9x for Sub-Prime. A severe shock increases them by 2.6x for Prime to 4x for Sub-Prime.

All random seeds are fixed to ensure reproducibility.

The 600 applicants comprise 111 Prime, 329 Near-Prime and 160 Sub-Prime applicants.

Profit and risk calculations

Each approved applicant’s exposure is the lower of the segment ticket cap and an affordability limit calculated as monthly income × FOIR × 36 months.

Applicants below the applicable CIBIL cut-off are declined.

Profit is calculated as a simplified one-period expected margin, excluding funding costs, operating expenses and loan tenure.

Here, NPA represents a simulated exposure-weighted expected default rate. It is not regulatory GNPA or NNPA under RBI asset-classification norms. The portfolio risk ceiling is assumed to be 2.5%.

Four methods, four different responsibilities

Think of these as four specialists supporting a credit committee.

1. NSGA-II: Mapping the risk-return frontier

What are the efficient combinations of profit and risk?

NSGA-II identifies multiple Pareto-efficient solutions rather than attempting to find one supposedly perfect answer. It helps the committee understand the profitability sacrificed for different levels of risk reduction. I used the NSGA-II sampler available in Optuna.

2. SLSQP: Establishing an optimisation benchmark

What is the best continuous solution under a defined mathematical formulation?

SLSQP is a gradient-based optimiser and provides a useful benchmark against which other approaches can be evaluated.

3. Optuna TPE: Searching deployable policy configurations

What works when policy variables have discrete, operationally implementable values?

TPE searches the actual decision grid: CIBIL cut-offs in steps of 10, FOIR limits and segment ticket caps. It does not require gradient information.

4. LinUCB: Personalising applicant-level execution

How should an approved policy be applied to individual applicants?

The contextual bandit selects from permitted ticket sizes, learns from outcomes and operates within centrally approved limits.

The distinction is important: the first three methods optimise portfolio-level policy configurations. The bandit makes applicant-level decisions within the approved policy boundary.

Credit lending also presents a challenge for contextual bandits. Defaults emerge with a time lag, rejected applicants do not reveal their repayment behaviour, and historical approvals influence the data available for learning.

Therefore, exploration must be constrained, reward definitions approved and offline policy evaluation performed before deployment. My simulation assumes immediate availability of default outcomes, which is considerably simpler than an actual lending environment.

The LLM coordinates these analytical capabilities. Deterministic code independently verifies constraints and refuses deployment unless stress testing and human approval requirements are satisfied.

The deployment control exists in code, not in the LLM prompt.

Three scenarios: three different decisions

Morning 1: Normal market

Portfolio NPA is 2.14%, comfortably below the 2.5% ceiling.

The agent does nothing.

Knowing when not to change policy is equally important.

Morning 2: Market stress

Near-Prime and Sub-Prime defaults increase by 1.5x and 1.9x respectively. Portfolio NPA rises to 3.16%.

The optimisation process begins.

• NSGA-II finds that ticket caps alone can reduce NPA to 2.23%, but profitability falls to Rs 128 lakh.
• SLSQP’s caps-only benchmark produces 2.30% NPA and Rs 144 lakh profit.
• TPE proposes ticket caps of Rs 10 lakh, Rs 3 lakh and Rs 2 lakh, a CIBIL cut-off of 690 and FOIR of 0.50.
• The resulting NPA is 2.28%, with profit of Rs 195 lakh, compared with Rs 189 lakh under the original policy.

The Sub-Prime ticket cap is immaterial in this configuration because the CIBIL cut-off already excludes the entire segment.

Independent verification passes. A simulated reviewer approves the proposal, and the policy is deployed.

Get Prasad Athalye’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The bandit’s permitted ticket sizes are also adjusted from Rs [1, 2, 3.5, 5, 7] lakh to [1.2, 2.1, 3.0] lakh.

Morning 3: Severe systemic shock

Default probabilities increase sharply. Even Prime breaches the 2.5% ceiling, with a simulated default rate of 2.6%.

Portfolio NPA reaches 4.88%.

The best TPE proposal reduces it to 3.11%, but this remains above the approved ceiling. A tighter retry also fails. The system refuses deployment and escalates the matter to the Human Committee.

Whether to accept an interim risk level of 3.11% is a Board-level decision, not an algorithm’s. For now, let us assume the Board is still relevant (just checking!).

Testing the algorithms on equal terms

The initial scenarios demonstrated the methods, but a fair comparison requires identical decision variables, constraints and evaluation budgets.

I therefore conducted a second experiment:

• Same objective: maximise profit.
• Same constraint: simulated NPA at or below 2.3%.
• Same decision variables and feasible ranges.
• Approximately 250 evaluations per run.
• Ten random seeds for each method.
• Five fresh synthetic populations to test the winning policies.

The results:

For SLSQP, the continuous solutions were also rounded to deployable values and rechecked. Only 7 of 10 remained feasible, with median profit of Rs 193.5 lakh.

Three observations stand out.

1. Decision variables matter more than algorithmic sophistication:Adding CIBIL cut-off and FOIR to the optimisation variables increased median profit from approximately Rs 143 lakh to Rs 198 lakh for SLSQP and TPE.

That is a gain of approximately 38% within this synthetic experiment. Before investing in a more sophisticated optimiser, examine whether the existing optimisation framework has access to all the relevant policy levers.

2. SLSQP and TPE perform similarly when given equal flexibility: Their median profits are within 1% of each other. However, SLSQP searches continuous values, whereas TPE searches deployable policy configurations directly. Once SLSQP outputs are rounded, three of its ten solutions breach the stricter 2.3% target.

This does not mean a gradient-based optimiser cannot discover useful policy thresholds. It means implementation constraints must be considered during optimisation, not merely after it.

3. The optimum is often a plateau, not a point: SLSQP produced winning policies with CIBIL cut-offs ranging from 678 to 707, with different segment ticket caps, yet similar profitability.

This is where human judgement becomes important. When several configurations deliver comparable financial outcomes, the committee can consider segment concentration, customer impact and operational simplicity before selecting one.

The five fresh populations also produced average simulated NPA between 1.98% and 2.08%, below the 2.5% ceiling.

These are fresh draws from the same underlying distributions. They test sample overfitting, not performance under an entirely different economic regime.

Guardrails have a price!

I also examined the impact of restricting the contextual bandit’s permitted actions. Across 20 simulation runs, each involving 1,500 stressed Near-Prime applicants:

Risk reduced by approximately 31%, while profit declined by approximately 45%. Both moved in the same direction across all 20 runs.

This illustrates an important point: risk controls have an economic cost. The committee should see that trade-off rather than assume that tighter controls are automatically better.

The intelligence is in the decision architecture

The experiment reinforces five distinctions:

• An LLM can interpret a situation, but interpretation is not optimisation.
• A predictive model estimates default probability, but prediction is not a policy decision.
• An optimiser identifies mathematically efficient alternatives, but mathematical feasibility is not regulatory acceptability.
• A contextual bandit learns from feedback, but learning is not automatically safe decision-making.
• Governance determines which decisions are permitted, under what conditions and with whose authority.

There is also an important dependency: an optimiser cannot rescue a defective risk model. It can only optimise the assumptions and estimates supplied to it.

Model calibration, drift monitoring and validation must therefore precede policy optimisation.

Similarly, autonomy must be constrained by approved objectives, exploration limits, validation thresholds and escalation rules. The ability to execute a decision does not confer the authority to make it.

The LLM: a specialist consultant, not a clerk

I would not invoke an LLM for every routine portfolio review.

A more sensible architecture is a combination of deterministic processing and exception-based intelligence.

Business-as-usual operations: A rule engine handles daily portfolio health checks, threshold monitoring and standard responses. It is inexpensive, predictable and auditable. The scripted planner in my experiment demonstrates this approach.

Dynamic or unusual situations: The LLM is invoked when multiple signals require interpretation, an unexpected situation arises or a decision-maker seeks an explanation of available alternatives.

For instance, a CRO might ask: “Why not simply tighten Near-Prime instead of changing the FOIR?”

This is where an LLM adds value by coordinating analytical tools and translating their outputs into business language.

It is also a question of token economy. Deterministic decisions belong in deterministic systems. Probabilistic reasoning should be invoked only when it adds demonstrable value.

On a normal day, the LLM consumes zero tokens because it is not called. When invoked, the system sends compact JSON summaries rather than raw applicant data, uses a fixed prompt that can be cached and enforces a hard execution limit.

One practical observation from my implementation: I requested analytical notes within 110 words, but Claude produced approximately 150 words in the stress scenario. Prompt instructions are not reliable controls. Anything that matters operationally must be enforced in code.

How the live Claude integration works

The conceptual orchestration flow is:

1. Portfolio telemetry identifies a risk breach.
2. Claude interprets the situation and selects the analytical tools.
3. Quantitative methods execute the optimisation.
4. Independent code verifies the proposed policy.
5. Claude prepares the recommendation for the human committee.
6. An authorised human approves or rejects deployment.

What the live run demonstrated

• Consistent execution: Claude selected the same sequence of analytical tools and produced the same quantitative results as the scripted planner in this run.
• Contextual interpretation: During the severe shock, Claude retrieved details of the previously deployed policy from the incident log and recognised that the earlier intervention was no longer sufficient. This demonstrates the usefulness of providing an LLM with operational context through tools, rather than relying on the model’s own memory.
• The importance of data semantics: Claude identified the FPD proxy as a potential early-warning signal. However, the proxy in this experiment was simply calculated as 1.4 times simulated NPA. It was not an independent indicator of future deterioration. This illustrates why the meaning and construction of input variables must be clearly established.
• Prompt instructions are not hard controls: Despite being asked to keep its notes within 110 words, Claude produced approximately 150 words in the stress scenario. Operationally important limits must be enforced through code.

How frequently should the system run?

My proposed operating rhythm, which has not been tested as part of this experiment, is:

• Daily: Rule-based monitoring of early-warning signals and portfolio guardrails.
• Weekly: Review of delinquency trends, segment behaviour and bandit drift.
• Event-triggered: Full optimisation when defined thresholds are breached. The LLM may be invoked at this stage.
• Quarterly or annually: Human review of risk appetite, structural policy and model validation.

Importantly, reported NPA is a lagging indicator. Early delinquency and other faster-moving signals should drive daily monitoring.

There is also a risk of policy churn. Frequent optimisation without adequate buffers can result in overreaction to temporary fluctuations.

My experiment uses a 0.2 percentage-point buffer below the approved risk ceiling. This is illustrative; an actual buffer should reflect portfolio volatility, estimation uncertainty and the cost of policy changes.

Honest caveats

A few limitations deserve emphasis:

• All applicants, market conditions and portfolio outcomes are synthetic. The results are demonstrations, not real-world performance benchmarks.
• The bandit receives immediate default feedback, unlike actual lending portfolios where outcomes emerge over months.
• The experiment assumes that underlying risk estimates are fit for use. It does not independently test probability calibration, model drift or rank-order deterioration.
• The five fresh populations are drawn from the same distributions. They do not establish robustness under structural changes in borrower behaviour or economic conditions.
• The live Claude integration was tested in one run. Quantitative outputs are reproducible under fixed inputs, configurations, software versions and random seeds; LLM tool selection and generated explanations may vary.
• Human approval is simulated. Production deployment must comply with applicable RBI directions, internal model-risk governance, technology controls and fair and explainable lending requirements.

The real question: How quickly can your institution respond?

The objective is not to remove judgement from credit policy. It is to provide decision-makers with better evidence, more alternatives and a faster way to evaluate the consequences of policy changes.

The underlying intelligence comes from predictive modelling, Bayesian optimisation, multi-objective optimisation, constrained optimisation and contextual learning, supported by reliable data and governance.

The LLM simply coordinates these capabilities and makes their outputs easier to interpret.

And importantly, this need not be a multi-year transformation before an institution can begin experimenting. A reasonably structured dataset, a working analytical environment and clearly defined business constraints are sufficient to demonstrate the concept. Production maturity can then evolve through validation, integration and governance.

The credit policy is a photograph; The portfolio is a film. Perhaps it is time the decision-making caught up.

I am happy to share the approximately 500 lines of code behind this experiment.

Which part of your credit policy would you like to move from periodic review to continuous decision intelligence?

#CreditRisk #DecisionScience #Optimisation #Lending #FinTech #AIAgents #DecisionIntelligence #India

The raw databricks outputs (explained above):

Warning: statements after `dbutils.library.restartPython()` will execute before Python is restarted.
Planner: Claude claude-sonnet-5-5
PLANNER: Claude  (model claude-sonnet-5-5)

========================================================================
SCENARIO 1: NORMAL TIMES
========================================================================
   TOOL get_portfolio_telemetry() -> NPA 2.14%

   NPA before 2.14% -> after 2.14%   |   NOTE TO CRO:
   Gross NPA is 2.14%, below the Board cap of 2.5%, so there is no breach. I'm not taking any action: no optimisation, no deployment and no bandit clamp.

Note to CRO: The daily health check shows gross NPA at 2.14% against the 2.5% Board cap, which leaves 0.36pp of headroom. The FPD proxy is 3.0%, capital used is 75%, and profit is Rs 199.8 lakh. The live policy has caps of 6/3/1, a CIBIL cut-off of 650 and FOIR of 0.4. The portfolio is healthy, so I ran no optimisers, deployed nothing and made no bandit changes. I'm unsure whether the FPD proxy of 3.0% points to NPA rising later. I'd keep watching it.

========================================================================
SCENARIO 2: MARKET STRESS
========================================================================
   TOOL get_portfolio_telemetry() -> NPA 3.16%
   [LLM thinks] Breach (3.16% vs 2.5%). Checking incidents first.
   TOOL recall_incidents() -> 0 past
   [LLM thinks] Target 2.3%.
   TOOL run_nsga2(target_npa=2.3) -> 2.23% / Rs128L
   TOOL run_slsqp(target_npa=2.3) -> 2.3% / Rs144L
   TOOL run_tpe(target_npa=2.3) -> P1 2.28% / Rs195L
   TOOL verify_policy(proposal_id=P1) -> PASS 2.28%
   [HUMAN APPROVAL] simulated reviewer approves P1 (NPA 2.28%, profit Rs 195L)
   TOOL deploy_policy(proposal_id=P1) -> deployed
   TOOL clamp_bandit(proposal_id=P1) -> [1.2, 2.1, 3.0]

   NPA before 3.16% -> after 2.28%   |   NOTE TO CRO:
   Gross NPA was 3.16% against the 2.5% cap, and FPD proxy was 4.43%. There were no prior incidents.

I deployed TPE proposal P1 after it passed verification. It has caps of 10/3/2, a cut-off of 690 and FOIR of 0.50. Projected NPA is 2.28%, profit is Rs 195.1 lakh (up from 189.2), and capital use is 80.3% (up from 75%). The bandit arms are clamped to 1.2, 2.1 and 3.0.

For comparison, the caps-only SLSQP benchmark reached 2.3% NPA with profit of only Rs 143.7 lakh. NSGA-II's best policy under the target had profit of Rs 127.5 lakh.

I'm unsure about three things:
- P1 beats the caps-only benchmarks on profit. That may depend on model assumptions about the stricter cut-off.
- Raising FOIR to 0.50 may add risk that the stress test doesn't capture.
- The higher capital use leaves less headroom.

I'd recommend monitoring actual NPA and FPD closely.

========================================================================
SCENARIO 3: SEVERE SYSTEMIC SHOCK
========================================================================
   TOOL get_portfolio_telemetry() -> NPA 4.88%
   [LLM thinks] Breach (4.88% vs 2.5%). Checking incidents first.
   TOOL recall_incidents() -> 1 past
   TOOL run_nsga2(target_npa=2.3) -> none feasible
   TOOL run_slsqp(target_npa=2.3) -> 4.74% / Rs108L
   TOOL run_tpe(target_npa=2.3) -> P2 3.11% / Rs95L
   TOOL verify_policy(proposal_id=P2) -> FAIL 3.11%
   [LLM thinks] Failed. One permitted retry with a tighter target.
   TOOL run_tpe(target_npa=2.0) -> P3 3.11% / Rs95L
   TOOL verify_policy(proposal_id=P3) -> FAIL 3.11%
   TOOL escalate_to_cro(reason=Gross NPA 4.88% vs 2.5% cap. Prior fix P1 (caps 10/3/2, cutoff 690, FOIR 0.5), now live, gave 2.28% in Oct but no longer works. Caps-only frontier bottoms at 4.82%. TPE proposals P2 and P3 (caps 10/1/1, cutoff 720, FOIR 0.5) reach only 3.11% NPA at profit Rs 95 lakh and failed verification. Retry budget used. Nothing deployed.) -> CRO notified

   NPA before 4.88% -> after 4.88%   |   NOTE TO CRO:
   Note to CRO: Gross NPA is 4.88% against the 2.5% cap. FPD proxy is 6.83%. The live policy is the same one that gave 2.28% in October, so it no longer works. Caps alone can't fix it. The best caps-only NPA is about 4.8%. TPE proposals P2 and P3 (cutoff 720, caps 10/1/1) only reached 3.11%, with profit falling from Rs 166 to 95 lakh. Both failed verification. I used my one retry, deployed nothing and didn't clamp the bandit. I'm unsure why the old policy stopped working. It may be a market shift or a data problem. Please decide whether to take a tighter cutoff, cut volume, or review the drivers.

MEMORY (incidents.json):
   {'date': '2026-10-29', 'market': 'stress', 'action': 'deployed', 'proposal': 'P1', 'policy': {'caps': [10.0, 3.0, 2.0], 'cutoff': 690, 'foir': 0.5}, 'npa_after': 2.28}
   {'date': '2026-10-29', 'market': 'severe', 'action': 'escalated', 'reason': 'Gross NPA 4.88% vs 2.5% cap. Prior fix P1 (caps 10/3/2, cutoff 690, FOIR 0.5), now live, gave 2.28% in Oct but no longer works. Caps-only frontier bottoms at 4.82%. TPE proposals P2 and P3 (caps 10/1/1, cutoff 720, FOIR 0.5) reach only 3.11% NPA at profit Rs 95 lakh and failed verification. Retry bu'}