Asking your loan book questions in plain English

Every risk and business team has a queue of portfolio questions waiting on an analyst. Why did PAR 30 rise in the West region last quarter? Which branches have the worst roll rate on loans booked this year? How much of the book sits with borrowers whose salary credits stopped? Each one needs someone who knows the tables, writes the query, checks it and sends back a spreadsheet.

Plain-English questions against the loan book are an obvious use for language models. They are also one of the easiest places to get badly wrong.

Why a model must not write the numbers

A language model produces text that looks right. That is a strength for drafting and a serious weakness for arithmetic on a portfolio. There are three common ways it fails.

• It invents figures. Asked for a ratio, a model may simply produce a plausible number. It reads as an answer and carries no warning.
• It writes a query that runs but means something else. A model asked to write SQL for "PAR 30" may count accounts instead of outstanding principal, include written-off loans, or use the wrong reporting date. The query returns a number, the number is wrong, and nothing signals the error.
• It defines terms differently each time. Ask the same question twice with slightly different wording and the model may build two different definitions of bounce rate. Two people in the same meeting then quote two numbers for the same metric.

In a regulated lender these are not small errors. Portfolio numbers drive provisioning discussions, board packs, collection strategy and credit policy changes. A number nobody can trace is worse than no number.

The model chooses; the database computes

A safer design splits the work. The language model does what it is good at, understanding the question. The lender's own database does what it is good at, computing the number.

It works like this:

1. The risk team defines its metrics once in a glossary: PAR 30, PAR 90, roll rate, bounce rate, collection efficiency, and whatever else the business tracks. Each entry holds the exact definition, the query that computes it and the dimensions it can be cut by, such as region, branch, product or booking month.
2. When someone asks a question, the model reads it and picks the right metric and filters from the glossary. "PAR 30 in the West region last quarter" becomes a reference to the PAR 30 entry, filtered by region and period.
3. The approved query runs against the lender's database. The number comes from the database, never from the model.
4. If the question needs a metric that is not in the glossary, the system says so instead of improvising one.

The model never touches the arithmetic. Its job is translation, and translation can be checked.

Agreeing the definitions

The glossary is where the real work happens, and it is mostly not technical work. Credit, risk, finance and collections often use the same word for slightly different things.

Take PAR 30. Is it outstanding principal on accounts more than 30 days past due, divided by total outstanding principal? Does the denominator include written-off accounts? Are restructured loans counted at their current bucket or their original one? Which date is the snapshot taken on? Roll rate raises similar questions: the share of accounts or the share of balance moving from one bucket to the next, and over which window. Bounce rate depends on whether a re-presented mandate counts once or twice.

None of these questions has one correct answer. Each lender has to settle them, write the answer down and get the people who report the number to sign off. A sensible process:

• One owner for the glossary, usually in risk or finance.
• A short written definition next to every query, in language a credit committee member can read.
• A review by the teams that report the metric before it goes live.
• Versioning. When a definition changes, the old version stays on record with the date it stopped applying, so last year's board pack can still be reproduced.

This discipline helps even without a language model.

Show the working behind every answer

A plain-English answer should never arrive alone. Alongside the number, the person asking should see:

• the glossary entry used, with its written definition and version;
• the filters applied, such as region, period and product;
• the query that ran, for anyone who wants to check it;
• the time the data was read.

This lets a Chief Risk Officer trust the number in a meeting, and lets an analyst reproduce it afterwards. It also makes misreadings visible at once, such as "booked this year" read as the last twelve months.

Access matters too. A branch manager may be allowed to see their own branch and not the whole book. The glossary query should run with the asker's permissions, not the system's.

Where Inferova fits

In Inferova's Worker, risk and business teams ask portfolio questions against a glossary the team defines once; the model selects the metric and the lender's database computes the result, inside the lender's own environment. The principle matters more than the tool: keep the model away from the arithmetic, and keep the definitions in the hands of the people accountable for them.

Questions to ask of any portfolio assistant

• Does the number ever come from the model, or always from your database?
• Who defines the metrics, and how are changes versioned?
• What happens when a question needs a metric that is not defined?
• Can every answer be traced to a definition, filters and a query?
• Does the query respect the asker's data permissions?

If you would like to try this approach on sample data from your own book, you can request beta access at inferova.com/demo.