Eligibility & Risk Scoring
Will assemble the fiscal picture behind a proposed sanction, with every factor shown as a figure.
A new sanction is usually assessed on a physical file and the committee's collective memory of the borrower, because the information that would inform the decision is scattered: existing exposure sits in one register, repayment behaviour in another, the entity's own accounts in a PDF someone emailed last year. In institutional on-lending the fiscal health of a borrowing entity is genuinely knowable (own-source revenue, grant dependency, existing debt service against receipts) but it is almost never assembled in one place at the moment the decision is taken. The result is not usually a bad decision. It is an undocumented one, which is harder to defend at audit and impossible to compare across cases.
The pipeline, stage by stage
Each stage names what goes in and what comes out, because a capability you cannot inspect is a capability you cannot audit.
- 01
Feature assembly
Designed to pull the borrowing entity's complete record inside the platform: repayment behaviour, current and historical exposure across schemes, waiver and restructure history, overdue episodes. It would add the fiscal indicators the lender supplies, such as annual accounts, own-revenue receipts and existing debt service.
- 02
Policy gate evaluation
Deterministic, and it would run before any score. The lender's own eligibility rules would execute as hard gates: exposure ceilings, scheme eligibility, arrears bars, minimum documentation, resolution validity. A gate failure is a rule outcome, reported as such. It will never be expressed as a low score.
- 03
Scoring with stated factors
For entities that clear the gates, a score and band, accompanied by the top contributing factors each expressed as a checkable figure: "debt service to own revenue at 41 per cent, against a policy comfort of 30 per cent" rather than "elevated borrowing risk".
- 04
Comparable set
The card will show similar entities from the book on the lender's chosen comparability basis (zone, population class, scheme, size band) and how their sanctions have actually performed, so the score is read in context rather than in isolation.
- 05
Recommendation packaging
A sanction envelope would be proposed: an amount range, a tenure, and conditions such as a longer moratorium or a stricter deduction mandate. These would attach to the sanction file as suggestions with their reasoning, alongside the officer's own note.
- 06
Decision capture
The committee's decision would be recorded, including a decision taken against the score, with reasons. That record is designed to be both the audit artefact and the monitoring signal used to review whether the score is behaving.
What it proposes, and what you approve
This is the architectural rule of the whole AI layer, made specific to this capability. Nothing a model produces reaches a balance on its own.
| Scoring would propose | A named human would approve |
|---|---|
| An assembled fiscal and exposure picture from platform and supplied data | The accuracy and currency of the supplied fiscal inputs |
| A pass or fail against each policy gate | Any override of a failed gate, with a written reason and the authority to do it |
| A score, a band and the factors behind it, as figures | No approval attaches to the score itself, which would be advisory and would carry no authority |
| A comparable entity set | The comparability basis, which is configuration |
| A suggested sanction envelope: amount, tenure, conditions | The sanction itself, through the existing maker-checker approval |
| A flag that the score is drifting or performing poorly | Suspension or recalibration of the score |
Shaped to your book, not shipped as one fixed version
These are the decisions you make and we build against. They are the reason two deployments of the same capability do not look alike.
- Which fiscal indicators you supply, and how often
Annual accounts, quarterly returns, own-source revenue, grant receipts, existing debt service. The indicator return is designed with you, because a municipal body and an NBFC's SME borrower do not report the same things.
- Policy gates and ceilings
Your exposure limits per entity and per scheme, arrears bars, documentation minimums, and whether each gate is absolute or overridable and by whom.
- Score bands and what they trigger
How many bands, where the cut-offs sit, and what each band changes in routing: additional approval, a condition, a committee referral, or nothing at all.
- Comparable set definition
What makes two borrowing entities comparable in your book: zone, population class, scheme, sanction size, or a combination you specify.
- Score visibility
Whether the committee sees the score, whether only the credit function sees it, and whether the borrowing entity is told anything beyond its gate results.
- Override authority
Who may decide against the score, what reason categories are recorded, and whether an override needs a second signature before the sanction proceeds.
Inputs
- The entity master
- internal repayment and exposure history across schemes
- waiver, restructure and write-off history
- fiscal statements or the agreed indicator return
- scheme rules, rate bands and ceilings
- the lender's written eligibility policy
- historical sanction outcomes, which is the input that makes the whole capability possible and the reason it is sequenced late
Outputs
| Artefact | Format |
|---|---|
| Eligibility gate result: pass or fail per rule, with the value tested | PDF, attached to the sanction file |
| Score card: band, contributing factors as figures, data as-of dates | |
| Comparable entity set with outcome history | Excel |
| Proposed sanction envelope with reasoning | Attached to the sanction record |
| Override register: decisions taken against the score, with reasons | Excel |
| Model performance pack: predicted against actual, by band and cohort |
The duties this creates
Duties, not job titles. Each one below is a permission you grant, so you map them onto the roles you already have. Preparing, approving and configuring are separate by design, which is how you stop one person holding two of them.
- Preparing the file
Assembles the sanction file and runs it through the gates.
- Reviewing a scored proposal
Reads the score card and the reasons behind it before the credit decision is taken.
- Overriding a gate
A distinct permission, because every use of it is written to the override register with a stated reason.
- Configuring
Owns the hard gates, the score bands, the indicators that feed them and the comparability rules.
- Supplying exposure figures
Provides and validates the existing-exposure numbers the score depends on.
- Reviewing after the fact
Reads gate results, score cards and the override register.
The borrower sees its gate results and the documents it still has to supply. The internal score is shown only if the lender chooses to disclose it.
What it will do when the data fights back
Any vendor can describe the happy path. These are the cases that decide whether a capability is safe to put near a loan balance. Designed behaviour in each case:
A first-time borrower with no internal history
The capability would return "insufficient basis to score" and issue the gate results alone. It will not produce a confident-looking number from three data points, because a spurious score on a thin file is more dangerous than no score, and committees treat numbers as harder than they are.
The supplied fiscal indicators are stale
The score would be issued as provisional, marked as such on the card, with the age of each input stated beside it. Beyond a configured staleness limit, scoring would be withheld rather than issued with a caveat nobody reads.
The committee decides against the score
The decision would proceed. The override would be recorded with a reason category and a note, and would appear in the override register and the performance pack. A high volume of overrides in one direction would be treated as evidence about the model, not about the committee.
A factor is a proxy for something the lender may not lawfully or fairly consider
The factor list would be restricted to indicators the lender has approved in writing, every factor would be visible on the card, and any factor could be removed. The working rule is simple: if a factor cannot be explained to the borrower, it does not belong in the model.
Distribution drift after a policy or scheme change
The performance pack would flag the drift, and scoring would be suspended for the affected cohort pending recalibration rather than continuing quietly against a world that has changed.
Why it sits where it does
A later build, and last of the seven. The constraint is data, not difficulty. A score is only meaningful when it has been tested against outcomes across many entities and several sanction-to-recovery cycles, and that history is created by the platform running, not by building the model earlier. Shipping this capability early would mean shipping a model trained on almost nothing, dressed as a decision aid, into a committee room. That is the one failure mode a lending product cannot recover from.
What has to exist first
- Multi-tenancy and tenant isolation
- several sanction-to-recovery cycles of platform history
- the lender's written eligibility policy expressed as testable rules
- an agreed fiscal indicator return with a defined submission cadence
- role-based data masking, because scoring inputs frequently include information not every role should see
What buyers actually ask about this
No: feature assembly, gate evaluation and scoring would all run inside your deployment against your data. Residency is fixed in the deployment agreement, which for a public body would normally mean in-country or government cloud, and the security page sets out the detail.
Not without an explicit, separate agreement from every party involved, and that is not the default design. The intended path is a model configured and calibrated on your own book as part of the co-build. That is precisely why the capability is sequenced late: it needs your history to exist first, and we would rather wait than borrow someone else's.
By reading it. Every factor would appear as a checkable figure against a stated policy comfort level, gate results would be rule outcomes rather than opinions, comparable entities would be listed, and the override register would show every case where the committee decided otherwise. If a score cannot be explained in a sentence a committee member can verify, it is a defect in the design.
The sanctioning authority, unchanged from today. The score would be advisory, it will never block or approve, and the decision record would show what was known at the time. What the capability would change is that the basis for the decision is written down and comparable across cases, which is a stronger position at audit than a file and a recollection.
Yes, and that split is deliberate. The gates would be deterministic rules from your own policy and many lenders will want those alone: they are checkable, uncontroversial and immediately useful. Scoring would layer on top and could be disabled entirely, restricted to the credit function, or run in shadow mode where it is recorded but not shown to the committee.
That is the normal case, and Document Intelligence is designed to read those returns into the indicator set with citations back to the page. Where extraction confidence is low the figure would be entered by a person, and either way the score card would state the as-of date of every input, so a committee can see it is reading a picture from last March.
Other capabilities
Migration Copilot
Will read your legacy loan book, rebuild every timeline and reconcile every balance.
See the designAnomaly & Reconciliation Guard
Will prove continuously that every balance reproduces from the event log, and flag what does not.
See the designAsk-Your-Portfolio
Will let you ask the loan book a question in your own language and get a figure you can trace.
See the designShape this one around your book
Bring your document formats, your languages and your thresholds. We will show you what this looks like against your own data.
45 minutes | On the live deployment | A straight answer on sequence