2026Lending / Property

TitleCheck

A loan against property lender could not disburse until a lawyer had read the whole file and proved the title was clean. That reading is now done before anyone opens the folder.

Chain of titleK. Nair1978R. Kumar1994S. Rao2006?2019no registered transferSeller2024Ownership must pass buyer to seller, unbroken, or the loan cannot proceed
Client
Lender, loan against property
Role
Sole engineer, end to end
Engagement
Build and handover
Scope
Ingest to title opinion

The Problem

Every file is a folder of scanned documents, and one question: can we lend against this property.

A lawyer and a team of analysts read every page of every file, much of it decades old and in more than one language, to establish that ownership passed cleanly from one hand to the next. It took weeks. In a market where a borrower is holding other offers, the slow lender loses the loan.

Deals lost to faster lenders

Files were routinely abandoned part way through review because the borrower accepted a quicker offer elsewhere.

Capacity fixed to headcount

Growth meant hiring more analysts and empanelling more lawyers, so volume and cost rose together with no way to separate them.

Quality varied by reviewer

Two analysts reading the same folder did not always reach the same conclusion, and nothing recorded why either had decided as they did.

Constraints

The non negotiables that ruled out the obvious approach.

Wrong is worse than slow

A missed encumbrance becomes an unrecoverable loan. The system had to be able to say it did not know, and be measured on how often it wrongly claimed certainty.

Every output needs a source

A regulator can ask two years later why a file was approved. Each extracted field carries its document, page and confidence, stored immutably.

The input is genuinely bad

Photographs taken at an angle in poor light, low resolution scans of carbon copies, and typewritten deeds with handwritten margin notes.

The team is not technical

Credit analysts, not engineers, operate this daily. Anything requiring a developer to adjust a rule would have died within a month.

How It Works

Read the folder the way a good analyst does: establish what each document is, then whether the documents agree with each other, then whether the story they tell has a hole in it.

01

Normalise before anything else

Deskew, correct perspective from phone photographs, denoise and run OCR per language. Everything downstream assumes clean page images, so this stage is allowed to be slow.

02

Classify the folder

Sorts a loose folder into its document types: sale deed, mother deed, encumbrance certificate, tax receipts, approved plan, RERA registration, KYC. Produces a checklist of what is missing, which is often the most useful output of the whole run.

03

Extract with confidence attached

Parties, survey number, plot area, consideration amount, dates and registration details. No field is stored without a page reference and a score.

04

Reconcile across documents

Compares the same fact as stated in different documents and surfaces disagreements rather than silently choosing one. A plot area that differs between the deed and the municipal record is a finding, not a rounding error.

05

Build the chain and look for the hole

Orders every transfer chronologically and tests whether each seller was the previous buyer. Where that fails, the gap is reported with the two documents that bracket it.

06

Hand the doubt to a person

Anything under threshold reaches a named reviewer with the source page beside it. The correction is stored and tightens the matching rules for that district.

PipelineNormalisedeskew, OCR per languagebelow thresholdClassify15 document typesbelow thresholdExtractfield plus confidencebelow thresholdReconcilecross documentbelow thresholdChainorder and find gapsbelow thresholdOpinionevidence reportbelow thresholdreviewer queue

The Hard Part

The same person, spelled four different ways, across forty years

Extraction is the easy half. The value is in deciding whether the Ramesh Kumar who bought in 1994 is the R. Kumar who sold in 2006. Get that wrong in one direction and you invent a break in ownership that does not exist, and reject a good loan. Get it wrong in the other and you certify a chain that has a stranger in the middle of it.

String similarity alone was not survivable. It confidently merged two genuinely different people who shared a common name in the same village, which is the single most expensive mistake this system can make.

What worked was scoring identity across several weak signals together: name similarity, father's name, address at the time of the transaction, and whether the dates are even physically possible. Each signal is weak alone. Together they separate most cases cleanly, and the ones they cannot separate are exactly the ones a human should be looking at.

The threshold is set deliberately cautious, so a meaningful share of identity decisions goes to a reviewer rather than being resolved automatically. That share is shown to the lender rather than hidden, because it is the reason they trust the decisions the system does make on its own.

Is this the same personDocumentName as writtenFatherScoreSale deed 1994Ramesh KumarKrishnan1.00Tax receipt 2001R. KumarKrishnan0.94EC 2006Ramesh K.Krishnan0.91Sale deed 2006Ramesh KumarGovindan0.42to reviewA different father's name outweighs an exact name match

Technical Decisions

What was chosen, and what was not

ChoiceWhyInstead of
PostgreSQLThe chain of title is a graph query over transfers, and range and exclusion constraints catch overlapping ownership periods at write time rather than in application code.A document store, which made ordering and constraint checks manual
Append only event logA regulator can ask why a file was approved two years ago. Nothing is updated in place, so any historical opinion can be reconstructed exactly as it stood.Mutable records with an audit table alongside
Per district rule setsSurvey number formats and document conventions vary by state and district. Rules are data, editable by an analyst, not conditionals in code.One national parser with special cases hardcoded
Redis backed job queueA single file can run to hundreds of pages of image processing. Work is chunked per page so a slow file cannot block the queue, and failures retry per page.Processing a file synchronously in one long request
Confidence floor per fieldDifferent fields carry different risk. A misread tax receipt date is recoverable, a misread party name is not, so thresholds are set per field rather than globally.One global accuracy target across all fields

Outcome

What changed for the business.

Opinions in hours, not weeks

A file is triaged and reconciled before a lawyer opens it, so legal time is spent on the findings rather than on the reading.

Capacity no longer tracks headcount

Analysts review exceptions instead of whole folders, so volume can grow without the review team growing with it.

Missing documents surface on day one

The folder checklist runs first, so a borrower is asked for what is absent immediately rather than a week into review.

Every decision can be defended

Each field carries its source document, page and confidence, so an approval can be reconstructed exactly as it stood when it was made.

In Hindsight

What I would do differently.

01

I built classification first because it was the satisfying problem. The lender's actual first question was always which documents are missing, which needed no classification at all. That checklist should have shipped almost immediately, and instead it arrived late.

02

The reviewer screen was an afterthought for the first month, and adoption stalled until it put the source page next to the extracted field. The human in the loop is a product surface, not a fallback.

03

Per district rules should have been data from the start. The first few districts went in as code, and unpicking them cost more than writing the rule engine would have.

Get in Touch

Have this problem?
Let's talk