The headline number from one NBFC engagement was a 68% reduction in approval turnaround, from a four-day baseline. The number that matters more is that risk controls tightened rather than loosened.
Those two facts are related, and the relationship is the whole design.
The reframing that makes it work
The instinct is to point a model at the credit decision. That is the one place it should not go first — not for technical reasons but for institutional ones. A risk committee is being asked to delegate the judgement it exists to exercise, and it will decline.
The alternative is to let automation do everything except approve: read the documents, extract the fields, verify them against sources, run the checks, score the file, and route it. The underwriter receives an assembled, verified file with the exceptions flagged, and makes the same decision they always made — considerably faster, on better information.
Approval authority never moves. The waiting does.
Where the four days actually went
Almost none of it in the decision. Timing an origination queue honestly usually produces something like this:
- Document intake and keying — a human reading a salary slip, a bank statement, a registration certificate and typing what they see.
- Chasing what is missing, often discovered late because nobody checked completeness at submission.
- Verification — bureau pulls, employer checks, banking analysis, each with its own latency.
- Queue time waiting for an underwriter with capacity.
- The decision itself, typically minutes.
Compressing the first four is where the 68% comes from. It is also why the credit standard is unaffected: nothing about how the decision is made changed.
What the system actually does
Document intelligence
Extraction from the documents Indian lending actually runs on — salary slips in a dozen formats, bank statements as scanned PDFs, GST returns, KYC documents. The engineering difficulty is not reading a clean document; it is handling a photograph taken at an angle in poor light, which is what arrives.
Every extracted field carries a confidence score, and low confidence routes to a human rather than proceeding quietly.
Verification and cross-checks
Bureau data from CIBIL, Experian, Equifax or CRIF; CKYC download; banking analysis on statements; consistency checks between what was declared and what the documents show. Each is logged as an auditable event, because a bureau pull is itself a regulated action.
Configurable scorecards
The credit policy stays where the credit team can see and change it — thresholds and weights as configuration rather than as code. A policy nobody in risk can read without an engineer is a policy the business has effectively outsourced.
Straight-through for clean files, humans for the rest
Files that pass every check with high confidence proceed. Anything with a discrepancy, a low-confidence extraction or a policy exception routes to an underwriter with the specific issue surfaced — not as a raw dump, which is the difference between assistance and extra work.
The audit trail is the commercial feature
Every decision on that platform carries a complete record: what was submitted, what was extracted and with what confidence, which checks ran and what they returned, what the score was, which threshold applied, and who reviewed it.
This is not engineering hygiene in a regulated sector. It is the condition of going live. RBI's expectations around outsourcing and automated processing assume you can reconstruct a decision, and a system that records only outcomes cannot.
It is also what let the risk function accept the speed. They were not asked to trust a model; they were given better evidence than the manual process produced.
What to watch
- Extraction confidence thresholds set by document type, tuned against real rejections rather than a benchmark.
- Bias testing on the scorecard, deliberately, across protected and proxy attributes — location fields are the usual accidental proxy in Indian lending.
- Explainability sufficient to give an adverse decision a reason. An unexplainable model is a regulatory problem before it is a technical one.
- Data residency, which for anything touching payment data is a hard constraint on where processing may happen at all.
The sequence that worked
Seven months, six engineers plus ML. Document extraction first, because it was the largest time sink and the easiest to measure. Verification second. Routing and straight-through processing last, once there was enough measured confidence to define the threshold honestly.
Underwriters ended up handling 3.2 times as many files a day — not by working faster, but by no longer doing the assembly.