An NBFC's Credit Team Should Not Wait Three Days for a Portfolio Answer

On a Monday, the head of credit at a mid-size NBFC asks a question that sounds simple: disbursement grew last month, so why did the 31–60 days-past-due bucket grow faster — and which branches drove it?

She does not get an answer on Monday. She gets a ticket number.

The analyst who can answer it pulls disbursement data from the loan origination system, repayment data from the loan management system, and collection follow-up status from a third tool. The three extracts use three different branch codes for the same branch. One file counts a loan as disbursed on the sanction date; another counts it on the first disbursal date. By the time the numbers are reconciled and the chart is built, it is Thursday — and the branch review meeting was on Wednesday.

The data was never missing. The route to it was three days long.

Why portfolio questions move so slowly

An NBFC's portfolio lives in pieces, and each piece was bought to do a different job:

• Origination holds the front of the loan. Applications, sanctions and disbursements sit in the LOS, keyed to the branch that sold the loan.

• Servicing holds the middle. EMIs, due dates, part-payments and days past due sit in the LMS, updated by the day-end process.

• Collections holds the ground truth. Field visits, promises to pay and actual recoveries sit in a collections tool — or in a spreadsheet on a regional manager's laptop.

A portfolio question almost always crosses all three. "Which branches drove the 31–60 DPD rise?" needs disbursement branch from the first system, overdue days from the second, and collection context from the third. No single screen in any of them can answer it, so a person becomes the integration layer — exporting, joining in a spreadsheet, and hoping the definitions matched this time.

Definitions are the quiet problem. DPD is not a vague word: under the RBI's clarifications, an amount is overdue when it is not paid on its due date, accounts are watched in bands running up to 30 days, 31–60 and 61–90, and an account overdue beyond 90 days is classified as a non-performing asset. If one analyst's extract treats a part-paid EMI as cleared and another's does not, the two DPD numbers will disagree — and the credit meeting will spend its hour arguing about arithmetic instead of branches.

What finance Domain Knowledge actually adds

A generic AI query tool can turn a sentence into SQL. That is not the hard part. The hard part is that "DPD", "disbursement", "collection efficiency" and "branch" have precise meanings inside one NBFC, and the SQL has to use those meanings every time, not rediscover them per question.

That is what AgentSQL Domain Knowledge is for. It is the finance vocabulary, metrics and rules of the customer's own book, built into the agentic core on the customer's own data and integrated into TridaPad:

• DPD buckets, defined once. Current, 1–30, 31–60, 61–90 and 90+ — counted from the due date of the oldest unpaid instalment, the way the day-end process sees it.

• Disbursement, defined once. First disbursal date, not sanction date, so growth numbers and DPD numbers describe the same loans.

• Branch, defined once. The disbursing branch, with the LOS and LMS branch codes mapped to one list, so a join cannot silently split one branch into two.

• Collection efficiency, defined once. Collections in the period against amounts due in the period — the same formula in every answer, every month.

AgentSQL itself is schema-aware with guardrails: it discovers the tables and joins, routes the question to its query-writing and dashboard skills, and verifies the output before showing it. Domain Knowledge is what sits on top of that schema awareness so the generated SQL speaks this NBFC's finance, not finance in general.

One question, start to finish

Here is the Monday question asked the AgentSQL way. The credit head types it into TridaPad's chat, in plain words:

"Show me loans in the 31–60 DPD bucket by branch for last month, with the share of each branch's live loans, and compare it with the month before."

AgentSQL applies the stored definitions — DPD from the oldest unpaid instalment, branch as the disbursing branch — and generates SQL against the servicing data. In PostgreSQL form, the core of it reads:

WITH loan_dpd AS (
  SELECT l.loan_id,
         l.branch_id,
         MAX(CASE WHEN i.amount_paid < i.amount_due
                   AND i.due_date < CURRENT_DATE
                  THEN CURRENT_DATE - i.due_date
                  ELSE 0 END) AS dpd
  FROM loans l
  JOIN instalments i ON i.loan_id = l.loan_id
  WHERE l.status = 'live'
  GROUP BY l.loan_id, l.branch_id
)
SELECT b.branch_name,
       COUNT(*) FILTER (WHERE d.dpd BETWEEN 31 AND 60) AS loans_31_60_dpd,
       COUNT(*) AS live_loans,
       ROUND(100.0 * COUNT(*) FILTER (WHERE d.dpd BETWEEN 31 AND 60)
             / COUNT(*), 1) AS pct_in_31_60
FROM loan_dpd d
JOIN branches b ON b.branch_id = d.branch_id
GROUP BY b.branch_name
ORDER BY pct_in_31_60 DESC;

The result lands as a small portfolio dashboard: one row per branch, the 31–60 count, the share of live loans it represents, and the prior month beside it for the comparison she asked for. The two branches at the top are where Wednesday's review should start — and this time the dashboard exists before Wednesday. When she follows up with "now show me the same branches for 61–90", that is a second question in the same chat, not a second ticket. The SQL stays visible under the chart, so the analyst can check the logic once instead of rebuilding it every month.

What this does not do

Three limits are worth stating plainly.

It does not repair the source systems. If the collections tool holds promises to pay that never reach the LMS, no query layer can see them; the connections have to include the sources the question actually crosses. It does not make regulatory calls. SMA and NPA classification runs through the NBFC's own day-end process under RBI norms — AgentSQL surfaces the portfolio numbers the credit team manages by, it does not classify accounts for reporting. And it does not remove the analyst. It changes her job from rebuilding extracts to checking definitions and SQL once, then answering harder questions with the time that frees up.

Start with the Monday question

Pick the one portfolio question your credit team asks every week — the DPD movement, the branch collection table, the disbursement-versus-delinquency view. Connect those sources to TridaPad once, write its definitions down as Domain Knowledge, and let the credit head ask it herself next Monday. If the answer arrives in the meeting instead of three days after it, the pilot has already made its case.

Try AgentSQL — plain-language questions over your own portfolio data, with your finance definitions built in. Questions about a pilot on your own data: data@tridalabs.com.