Connecting a Loan Origination System to Property Verification: API Design Guide

At the centre of mortgage operations sits the bank's loan origination system (LOS). Each credit decision, document and disbursal trigger lives in it. In most Indian lenders, though, property verification still happens outside the LOS: panel advocates reached over email, scanned PDFs piling up in shared folders, and someone keying 'clear / conditional / rejected' into the system by hand. That gap causes most of the disbursal friction, the missed exceptions and the audit headaches in bulk mortgage operations.

Product and tech ops teams in banks, NBFCs and HFCs are the audience here. The guide covers where verification belongs in the LOS funnel, what an end-to-end API integration looks like, the payload structures both sides need to agree on, and the security and idempotency points that matter at go-live.

Meaning of LOS integration for property verification

It is API-level wiring between the bank's loan origination system and a property title verification service, internal or external. Legal verification then becomes an automated step in the loan workflow and not a manual side-process. In a properly integrated flow the LOS starts the verification, gets structured status updates, takes in the final legal opinion as machine-readable fields and not just a PDF attachment, and blocks disbursal on those fields, with no rekeying by hand.

The integration is not the goal. The goal is for the LOS to be the single source of truth on the legal status of the file, while the property verification system works as a service that can be called and not as a department.

The place of property verification in the LOS funnel

A typical mortgage LOS funnel in India runs like this:

• Capture of the lead and application
• KYC, verification of income, pull from the credit bureau
• Eligibility and sanction-in-principle (SIP)
• Collection of property documents
• Technical valuation
• Legal scrutiny or title verification
• Approval by the final credit committee
• Loan agreement and disbursal
• Monitoring after disbursal

Verification fits at step 6, once sanction-in-principle is done and before disbursal. At an earlier point you spend legal fees on files that may never be sanctioned. The worst case is verification after disbursal. Some HFCs and cooperative banks still do it, and any defect then appears with the money already out.

In the best LOS, verification starts by itself when steps 4 and 5 are finished, steps 6 and 7 run side by side where they can, and the structured verification response gates step 8. To see what verification must cover, read our property due diligence checklist for India and the home loan property due diligence requirements of banks.

Patterns for API integration

Indian LOS vendors commonly use three integration patterns. Each has its place, and combining them on purpose is usually the right call.

• Webhook-driven (async) · Mechanism: the LOS POSTs the file, the verification service returns a request_id, and callbacks fire on each status change and at completion · Best for: high volumes and parallel processing · Trade-off: the LOS must handle async state and signed webhooks
• Status polling · Mechanism: the LOS POSTs the file and calls a status endpoint every N seconds or minutes until the job completes · Best for: older LOS platforms with no webhook listener · Trade-off: heavier infrastructure load, and poll loops can drift out of sync
• Document push/pull · Mechanism: the LOS sends documents to a shared bucket or through the API, the verification service pulls them, and the report returns as PDF plus JSON · Best for: banks whose network policy permits outbound traffic only · Trade-off: slower, and real-time gating is harder

Most modern LOS integrations in practice use webhooks for status events and document push for retrieving evidence. This hybrid keeps the real-time signal light and keeps heavy files off the synchronous path.

The whole workflow, end to end

A round trip between a well-integrated LOS and the verification service goes as follows:

Sequence, read top to bottom. 1. LOS to service: POST /verifications carrying the property and the applicant. 2. Service to LOS: 201 Created, body holds request_id and status 'queued'. 3. Inside the service: retrieval in parallel of EC, eCourts, RERA, mutation and lis pendens data. 4. Service to LOS: webhook with status 'processing'. 5. Inside the service: AI pre-analysis, then advocate review. 6. Service to LOS: webhook with status 'completed'. 7. LOS to service: GET /verifications/{request_id}, answered by 200 OK with the full structured report. 8. LOS to service: GET /verifications/{request_id}/report.pdf, answered by 200 OK with the signed PDF artefact. 9. Inside the LOS: legal_status and disbursal_gate are written on the loan record.

Steps 1 and 2 start the job. Steps 3 to 5 are status webhooks that the LOS listens for. In step 6 the LOS pulls the structured JSON and writes it into its own tables. Step 7 fetches the signed PDF for the audit file. Step 8 updates the loan record with derived fields that downstream systems read.

The request payload

A verification request needs at least the property details, the applicant details, references to documents, and routing metadata. A typical request body is shown below:

{ "lender_reference_id": "HL-2026-AP-018734", "idempotency_key": "HL-2026-AP-018734-v1", "tier_hint": "tier_2_resale_residential", "loan_account_number": null, "applicant": { "applicant_type": "primary", "co_applicants": 1, "name": "Ravi Krishna Murthy", "pan_masked": "ABCPK****J" }, "property": { "address": { "pincode": "500081", "state": "TS", "district": "Hyderabad", "city": "Hyderabad", "locality": "Madhapur", "plot": "Plot 14, Survey 217/A" }, "property_type": "residential_apartment", "ownership_type": "freehold", "built_up_sqft": 1240, "identifiers": { "survey_number": "217/A", "khata_number": "MDP/14/2018", "rera_id": "P02400006712" } }, "documents": [ { "type": "ec_30yr", "fetch_required": true, "uri": null, "hash": null }, { "type": "mother_deed", "uri": "s3://lender-docs/HL-2026-AP-018734/title/mother.pdf", "hash": "11b9...c842" }, { "type": "sale_deed", "uri": "s3://lender-docs/HL-2026-AP-018734/title/sale.pdf", "hash": "9a87...3e4f" } ], "webhook": { "url": "https://los.lender.com/webhooks/verification", "secret_id": "wh_secret_018" } }

A few fields repay their place in the schema:

• With tier_hint the verification service can choose the right SLA tier at once and does not need to work it out again.
• A true fetch_required means the LOS does not hold the document and is handing retrieval over. This is common in AP, TS, KA and MH, where the EC from the portal is dependable.
• If the network drops between the POST and the 201, idempotency_key keeps the retry from creating a duplicate verification.
• The sha256 hashes fix the exact version of every document, which is critical for an audit two years later.

The response payload

Here most LOS integrations invest too little. A PDF-only response wastes 80% of the value. A structured response lets the LOS gate disbursal on fields a machine can read. A schema that is minimal but useful follows:

{ "request_id": "ver_018734_a7c2", "lender_reference_id": "HL-2026-AP-018734", "status": "completed", "version": "v1.4", "completed_at": "2026-05-14T11:42:18+05:30", "outcome": { "verdict": "clear", "verdict_confidence": 0.94, "marketability": { "marketable": true, "conditions": [] } }, "checks": { "mutation": { "source": "TS_mutation_portal", "khata_number": "MDP/14/2018", "mutation_complete": true }, "rera": { "compliant": true, "registered": true, "id": "P02400006712" }, "litigation": { "courts_searched": ["district_hyd", "hc_ts", "sc_india"], "ecourts_results": 0, "lis_pendens_flag": false, "litigation_flag": false }, "encumbrance": { "registered_mortgages": [], "discharged_charges": 2, "active_charges": 0, "ec_validity_to": "2026-05-13", "ec_validity_from": "1995-06-01" }, "title_chain": { "gaps": [], "complete": true, "years_covered": 30 } }, "sign_off": { "advocate": "Adv. S. R. Reddy", "enrolment": "AP/8821/1998", "time": "2026-05-14T11:38:02+05:30" }, "artefacts": { "legal_opinion_pdf_uri": "https://api.legiscore.in/v1/verifications/ver_018734_a7c2/report.pdf", "raw_evidence_uri": "https://api.legiscore.in/v1/verifications/ver_018734_a7c2/evidence.zip" } }

Downstream automation needs the LOS to capture these fields without fail:

• verdict: clear, conditional or rejected. This is the gate for disbursal.
• verdict_confidence: handy for credit committee dashboards. A clear verdict with low confidence should go for review.
• active_charges: a number above zero means a live lien that has to be cleared before disbursal.
• ec_validity_from and ec_validity_to: both belong in the LOS audit log, since storing just the EC date, as many LOS platforms do, falls short.
• litigation_flag and lis_pendens_flag: boolean gates that should send the file to the legal officer queue regardless of the verdict.
• mutation_complete: anything but true holds disbursal until mutation is closed.
• marketability.conditions: an array of the conditions behind a conditional verdict. The LOS must track each condition as its own to-close item.
• panel_advocate.bar_number: required for audit. Many LOS platforms omit it, and the panel's attestation is then harder to defend later.

If you want the legal meaning of these fields, our pieces on encumbrance certificates, 13-year vs 30-year title chain verification, and the legal opinion format explain it.

Idempotency, retries and reliable webhooks

Most LOS integrations get this part wrong in their first version.

• Idempotency keys on each POST: within a 24-hour window, a POST that repeats an idempotency key must return the same request_id. Otherwise a retry on an unstable network creates a second verification, with a second fee to the panel advocate.
• Exponential backoff on retries: both retries from LOS to service and webhook retries from service to LOS should back off exponentially with jitter (for example 1s, 2s, 4s, 8s, 16s, 30s, then capped). Tight retry loops in production set off cascading failures.
• Webhook payloads that are signed: every webhook should carry an HMAC signature made with a shared secret, and the LOS must check the signature before processing. Unsigned webhooks are a known attack surface.
• Protection against replay: put a timestamp and a nonce in every webhook, and reject any that is more than 5 minutes old or repeats a nonce already seen.
• Acknowledgement contract for webhooks: the LOS has to answer 200 within 5 seconds for a webhook to count as delivered, otherwise a retry follows. Do the business processing asynchronously on the LOS side.
• A job to reconcile status: each night, query the verification service for every request_id still in a non-terminal state on the LOS, and reconcile. Webhooks fail, and reconciliation catches what they miss.

LOS vendors common in India

• Lentra · Architecture: cloud, API-first · Integration note: it has a native webhook listener, and the structured response maps neatly
• Finbox · Architecture: cloud, modular · Integration note: some deployments favour status polling over webhooks
• Salesforce FSC / nCino-style · Architecture: SaaS with Apex callouts · Integration note: outbound is easy, while inbound webhooks need a public endpoint and authentication
• TCS BaNCS, Finacle, Newgen LOS · Architecture: on-premise, legacy core · Integration note: a middleware layer is usually needed, and document push/pull dominates
• In-house LOS (large PSU banks) · Architecture: on-premise, close to the mainframe · Integration note: built on an ESB or message queues, with webhooks delivered through an internal MQ

Legacy on-premise stacks nearly always need middleware between the LOS and an external verification API. Cloud-native LOS platforms can take webhooks directly. What you negotiate is the contract of request schema, response schema, webhook events and idempotency rules. The wiring is secondary.

Points on security

These APIs move PII (PAN and applicant name), identifiers of the property and signed legal documents, so bank security teams will rightly insist on the controls below:

• mTLS for calls going out from the LOS: client certificate authentication on top of HTTPS, which is standard for traffic between banks' APIs.
• Field-level encryption of PII: PAN, applicant name and phone number are encrypted at rest and decrypted only for entitled access.
• Document URIs as signed, time-limited URLs: pre-signed URLs that expire in 1-4 hours, never raw bucket paths.
• An audit log of each API call: request ID, timestamp, response code and latency, pushed to the bank's SIEM and not merely held in the verification service's logs.
• RBAC on the verification service side: a request from Lender-A can never be returned to Lender-B, and multi-tenant isolation has to be testable.
• Data residency: for Indian lenders, data should remain in Indian data centres, which most banks now treat as a procurement requirement.
• A flow for the right to erasure: a documented route to delete data when an application never reaches disbursal. Formalisation is still pending at most Indian banks, but it is on the way.

The LegiScore verification API supports all of this out of the box: async webhooks with HMAC signing, idempotency keys, a structured JSON response with the full field set above, signed PDFs for audit, mTLS support and data residency in India. Our piece on AI property verification vs manual due diligence compares this approach with manual workflows.

Where LOS integrations usually fail

• Response with PDF only: the LOS files the report as an attachment and someone rekeys the verdict. A person gates disbursal and the system does not.
• No idempotency keys: an unstable network produces duplicate verifications, and finance finds out from the vendor invoice at month-end.
• No structured array of conditions: conditional verdicts are handled like clear ones because nobody parsed out the conditions.
• A webhook listener that does not verify signatures: it will be exploited sooner or later. Always sign webhooks.
• No reconciliation job: files sit in processing without end because the webhook for completion was dropped.
• No mutation_complete gate: disbursal goes through on properties whose mutation is still pending, and the problem appears in the next mutation cycle.

What to plan for the next integration sprint

• Settle the schemas for request and response, with versions pinned.
• Implement an idempotent POST, a listener for signed webhooks, a structured GET and a fetch for the PDF.
• Feed the disbursal gate from verdict, active_charges, litigation_flag, lis_pendens_flag, mutation_complete and the conditions array.
• Build the reconciliation job, and show it on the on-call dashboard.
• Pin each document by SHA-256 in the request, and keep the evidence URIs on the LOS side.
• Run 2 weeks of shadow mode, with verification in parallel to the manual workflow, before you switch the disbursal gate over.