AI document processing for a lending company

The situation

Picture a mid-sized NBFC lending personal and small-business loans across Maharashtra and Karnataka. Applications arrive through its app, through direct selling agents on email and through branches that scan paper files in bulk. A typical file holds PAN and Aadhaar, two or three payslips or an ITR, and six months of bank statements, often as phone photos taken at an angle.

An operations team of around twenty people opens each file, works out what is in it and retypes names, salaries, EMIs and balances into the loan origination system. Underwriters then re-check much of the same data because they don't fully trust it. A clean file can take a day to reach credit. A messy one takes three, and good applicants go to a faster lender in the meantime.

The bottleneck isn't judgement. It's reading. The lender needs the reading done reliably and quickly, with a clear trail of where every number came from, while credit decisions stay exactly where they are.

Signs this blueprint fits you

• Your ops team retypes the same fields from the same five or six document types every day.
• Underwriters spend time checking data entry instead of assessing risk.
• Turnaround time varies wildly depending on how messy the uploads are.
• Auditors ask where a figure came from and the answer takes a while to find.

What we'd build

• An intake service that takes files from the app, the DSA inbox and branch scanners, splits multi-document bundles and orders statement pages.
• Classification and extraction that identifies each document type and reads the agreed fields into a fixed schema, with a confidence score for every value.
• A cross-check engine that compares values across documents and against your credit policy, using rules your credit team writes and owns.
• A review screen where ops staff see the original page next to the extracted fields and resolve only what was flagged.
• An integration with your loan origination system that sends verified data, flags and reviewer notes, not raw files.

How the pieces fit

Intake

Every file, whatever the channel, lands in the same queue in your cloud account. The intake step splits a 30-page scan into its documents, rotates and de-skews photos, and spots pages that are too blurred to read so the applicant can be asked for a new one straight away rather than days later.

Reading

We combine conventional OCR with a vision-capable language model. OCR is fast and precise on clean printed text. The model handles layouts that vary by bank and employer, which is where template-based tools usually break. Output is always structured: a set of named fields with values, confidence scores and the page region each value came from.

Checking

The rules are plain and testable: name and date of birth must match across KYC, payslip and statement; average salary credits should be within a set percentage of net pay; no unexplained EMI bounces in the last three months. Your credit team can read and change these rules without touching the AI.

Reviewing

Anything below a confidence threshold, and anything that fails a check, goes to a human queue. Everything else is pre-filled for the underwriter. The aim isn't to remove people from the process. It's to have them look only at what needs a look.

One loan file, end to end

Here is a salaried applicant's file traced from upload to underwriting, including one mismatch that needs a person.

The flag in this example is typical: payslips and bank credits rarely match to the rupee, because of deductions after net pay or reimbursements paid separately. The rules decide how much difference is acceptable, and the reviewer decides what to do with the cases outside it. Either way, the decision and the reason are recorded against the file.

What your operations team would see

The review screen is built for speed. The original page sits beside the extracted values, the region each value came from is highlighted, and only flagged or low-confidence fields need attention. Reviewers can accept, edit or flag a value, and every edit is stored with their name and the time.

Documents and fields in phase one

Data and integrations

Delivery plan

We'd start with one product line, usually salaried personal loans, because the documents are the most standard. The pipeline runs in parallel with the manual process for two weeks, and every file is compared. Only when field-level accuracy meets the bar agreed in week two does the team switch over, product by product.

The team

From your side: an operations lead for about three hours a week, a credit manager for the rules workshops, and someone from IT for cloud access and the LOS API.

What changes the effort

• Document variety. Salaried files are fairly standard. Self-employed files with GST returns, audited accounts and handwritten ledgers take longer.
• Number of banks in statements. Most layouts are handled by the model, but a long tail of small co-operative banks needs extra test data.
• LOS integration. A documented API is quick. Writing to a legacy system through a staging table or RPA takes longer.
• Accuracy bar. A higher auto-accept bar means more review volume at first and more tuning to bring it down.
• Languages. English and Hindi documents are the baseline. Regional-language statements add testing.

Risks and how we'd handle them

What we'd measure

Build or buy?

There are good off-the-shelf document AI products, and for standard KYC extraction one may be enough. A custom pipeline makes sense when you need your own cross-checks between documents, when statements come from many banks in many layouts, when the output has to land in your LOS in a specific shape, and when your compliance team wants documents to stay in your own cloud. We're happy to use a commercial OCR or KYC service inside the pipeline where it's the better tool; the custom part is the checks, the review flow and the integration.

Questions we'd ask on the first call

• Which product line has the most volume and the most standard documents?
• Which fields does your credit team actually use from each document?
• What tolerance between payslip and bank credits do you accept today?
• How does data get into your LOS now, and is there an API?
• What does your compliance team require for data storage and model use?

FAQ

Can it read handwritten documents?

Partly. Printed documents and forms are the strong case. Handwriting, such as manual ledgers, is read with lower confidence and usually routed to review.

Does this replace our KYC provider?

No. Existing KYC and bureau checks stay as they are. The pipeline reads the documents and checks them against each other and against those results.

How do you measure accuracy before we go live?

We label a sample of your past files in the first weeks and measure accuracy per field and document type against it. The parallel run then checks the same thing on live files.