AI for lending that leaves an audit trail.

The documents a lending file contains

A lending file is the documents assembled for one application: statements for the nominated account, proof of income, and identity and address records. The scope is which of them the system reads, which fields it owns, and which decision those fields feed.

Bank statements are the hard case. Layouts differ by bank, tables run across pages with a carried balance, debits and credits arrive as separate columns or one signed column, and narration encodes UPI handles, cheque numbers and mandate references. One applicant sends a digital PDF, the next a photograph of a printout, so the intake mix is part of what the sprint establishes.

Variable components on a payslip should not be counted as recurring income without a rule that says so. Self employed applicants bring income tax returns with the computation of income, certified financials for the years the lender requires and Form 26AS, with GST returns where the applicant is registered; those financials are tables rather than fields. Consented transaction data from an account aggregator removes the parsing problem rather than solving it.

Field-level accuracy and what a wrong field costs

A document level accuracy figure averages over fields of very different consequence: a pipeline reported as accurate overall can be failing on the field that moves money. A wrong character in an account number or IFSC rarely misroutes a payment, because the code is checked against the published master list and the beneficiary name is verified before disbursal; it fails the disbursal or blocks mandate registration instead and leaves an operations team reconciling a break. Those fields therefore carry format and checksum validation before any confidence threshold applies.

Confidence and provenance are carried per field. Model confidence is not calibrated out of the box, so a threshold is fitted rather than chosen: the evaluation set gives the review rate and the miss rate at each cut-off, and the threshold is set from that curve per field and recalibrated with any model or prompt change.

The threshold on a field follows its consequence. Figures feeding eligibility are held tighter than an employer address, some fields are never accepted without review, and where no decision depends on a field it still has to be extracted but needs no threshold and no gate. A misread net salary changes an eligibility calculation; a date of birth that disagrees with the identity record is a KYC exception.

Reconciliation against the system of record

Statements carry arithmetic that few other documents do: opening balance, transactions and closing balance have to agree. Where a statement prints a per page carried balance, the foot of one page has to match the head of the next, which gives extraction a check independent of the model, but not every bank template prints one.

When a period does not close, the cause may be a dropped, duplicated or misread row, a misread opening figure, entries the statement excludes, a hold separating cleared from available balance, or alteration. The pipeline records that it did not close and the size of the gap, and leaves the cause to a reviewer. Alteration changes a file hash by definition, so hashing never detects it; the signals there are inconsistent fonts or metadata within one file and a text layer that disagrees with the rendered image. The same file arriving on two applications is recorded but is usually benign.

The origination or core banking platform remains the system of record. Writes are keyed on the application identifier together with the operation and the version of the value being written, so a retry of the same write is absorbed while a genuine later correction is not. They happen after approval rather than at extraction, respect end of day batch windows, and a scheduled comparison with what the origination system holds surfaces divergence before an audit does.

Where the system stops: decisions, advice and borrower contact

The boundary is architectural. The system extracts, normalises, reconciles and presents. No model here scores an applicant, ranks a queue by likelihood of approval or recommends an outcome: credit scoring and credit policy are the lender's own, built and validated under the lender's model governance, and they sit outside what we are contracted to build.

Nor does the system give financial advice, recommend an investment or tell a borrower which product to take. A borrower facing assistant can say which documents are required, what stage an application has reached or what a clause in a signed agreement says; the retrieval engineering for that is on the RAG chatbot development page. Questions asking for advice, an eligibility verdict or a rate are routed to a person.

Automated borrower contact for arrears is scoped separately or not at all. EMI due dates and mandate presentation dates concentrate failed presentations into the same days each month, but permitted hours, what may be said and who may say it are conduct matters rather than engineering ones, so anything beyond a factual notification is routed to your own collections team. Where outbound contact is in scope, consent and calling windows are designed first; that work is on the voice AI agents page.

Maker-checker gates and the audit record

Lenders already run maker-checker, so the gates belong inside that control rather than beside it. Credit operations check extracted fields against the source page, a credit officer holds the gate on anything feeding eligibility, and the disbursal account, IFSC and mandate details take a second approver. The gate sits before the write, so the origination system never holds a value nobody approved.

The queue shows the value, its confidence and the original page beside it, so a reviewer checks against a source instead of retyping a statement. A correction is stored as a correction rather than overwriting the value, because it is what an auditor reading that file later will see.

The audit record is per field: the document hash, the model and prompt version that produced the value, what validation and reconciliation returned, who approved or changed it, and the reason recorded for an override. It has to survive a file reopened months later in an internal audit or a borrower dispute, so versions are pinned and a provider side update is re-evaluated rather than absorbed quietly.

Data residency, masking and retention

Sending a page to a model provider is a transfer of borrower data, so provider region, retention of inputs and whether a self hosted model is required are settled before the pipeline is built. In India the constraints are concrete: the RBI digital lending framework limits what a lending service provider may store at all and expects borrower data to sit on servers in India, KYC records carry a defined retention period under the Master Direction on KYC and an upload to the central KYC registry, and the DPDP Act adds consent and purpose limitation. We scope these requirements with you rather than advise on them as a legal matter.

Inside the perimeter the work is minimisation. Aadhaar is redacted at ingestion rather than after indexing and is not held in full, PAN is generally retained as an identifier, account numbers are tokenised for steps that do not need them, and access to an original page image is narrower than access to the extracted fields. Retention obligations and deletion once a purpose ends pull against each other, so the schedule is agreed per document class.

Evaluate per field against real application files

The evaluation set comes from completed applications, but the values held in the origination system are what a person keyed rather than ground truth and carry their own error rate. Establishing the reference values is part of the work, by double keying a sample or adjudicating disagreements against the source document, and the measured rate is reported against that reference.

Scoring is field by field and stratified by what varies in your intake: issuing bank and template, digital PDF against scan against phone photograph, password protected files, months submitted, salaried against self employed. An aggregate figure over an unstratified sample hides one bank template that fails completely. Files that are not clean extractions belong in the set too, scored on whether they were routed and flagged rather than on what was extracted.

Because the files are real borrower data, the evaluation set is a processing purpose in its own right, held under production controls and masked on the same rules as the pipeline. Where the retention schedule leaves too little for a regression set, a synthetic or redacted set is the alternative, at a cost in realism.

What a lending document project costs

Every engagement starts with a fixed-price discovery sprint at USD 2,500 over two weeks, which produces the architecture, initial screen designs, acceptance criteria, a running-cost model and a fixed price for the build. The sprint fee is deducted from the build.

Load is rarely flat, and its shape is in your own intake records: campaign windows, month and quarter boundaries, the fiscal year end and seasonal demand each move volume, so throughput and reviewer capacity are sized against the peak those records show. Running cost then scales with pages rather than applications: recognition and model inference per page, reprocessing when an applicant replaces a document, and reviewer time on flagged fields. A self employed file can carry several times the pages of a salaried one, because more months and more accounts are usually requested, so the page count per applicant type is measured from your intake.

Hosting inside the required region, document storage and audit log storage do not scale with volume, and charges passing through your own agreements, such as bureau pulls or account aggregator fetches, are listed separately.

Part of the AI Feature Implementation Sprint → · Explore our work → · Discuss an AI project →