LOS Integration for Property Verification: API Workflow for Loan Origination Systems

A bank's loan origination system (LOS) is the spine of mortgage operations — every credit decision, document, and disbursal trigger lives there. Yet in most Indian lenders, property verification still sits outside the LOS: email threads to panel advocates, scanned PDFs in shared folders, manual entry of "clear / conditional / rejected" back into the system. This integration gap drives most of the disbursal friction, missed exceptions, and audit headaches in bulk mortgage operations.

This guide is for product and tech ops teams inside banks, NBFCs, and HFCs. It covers where property verification belongs in the LOS funnel, what an API integration looks like end-to-end, the payload structures both sides must agree on, and the security and idempotency considerations that matter when you go live.

What "LOS integration for property verification" actually means

LOS integration for property verification is the API-level wiring between a bank's loan origination system and an external (or internal) property title verification service, such that legal verification becomes an automated step in the loan workflow rather than a manual side-process. A properly integrated workflow lets the LOS trigger verification, receive structured status updates, ingest the final legal opinion as machine-readable fields (not just a PDF attachment), and gate disbursal on those fields — all without manual rekeying.

The point is not the integration itself. The point is that the LOS becomes the single source of truth for the file's legal status, and the property verification system becomes a callable service rather than a department.

Where property verification sits in the LOS funnel

A typical Indian mortgage LOS funnel:

1. Lead capture and application
2. KYC, income verification, credit bureau pull
3. Eligibility and sanction-in-principle (SIP)
4. Property documents collection
5. Technical valuation
6. Legal scrutiny / title verification
7. Final credit committee approval
8. Loan agreement and disbursal
9. Post-disbursal monitoring

Property verification belongs in step 6 — after sanction-in-principle, before disbursal. Earlier wastes legal cost on files that may never sanction. After disbursal — which still happens in some HFCs and cooperative banks — is the worst outcome because defects surface when the money is already out.

A best-in-class LOS triggers verification automatically once steps 4 and 5 are complete, runs steps 6 and 7 in parallel where possible, and uses the structured verification response to gate step 8. For the underlying expectations of what verification must cover, see our property due diligence checklist for India and the bank-specific home loan property due diligence requirements.

API integration patterns

There are three integration patterns in common use across Indian LOS vendors. Each has a place; mixing them deliberately is usually right.

In practice, most modern LOS integrations use webhook-driven for status events and document push for evidence retrieval — a hybrid that keeps the real-time signal lightweight and the heavy artefacts out of the synchronous path.

End-to-end workflow

A well-integrated LOS-verification round trip looks like this:

LOS                                    Verification Service
 |                                              |
 | 1. POST /verifications (property + applicant)|
 |--------------------------------------------->|
 |                                              |
 |                 201 Created                  |
 |               {request_id, status:           |
 |                "queued"}                     |
 |<---------------------------------------------|
 |                                              |
 |                                              | 2. Run parallel retrieval
 |                                              |    (EC, eCourts, RERA,
 |                                              |     mutation, lis pendens)
 |                                              |
 |   3. Webhook: status="processing"            |
 |<---------------------------------------------|
 |                                              |
 |                                              | 4. AI pre-analysis +
 |                                              |    advocate review
 |                                              |
 |   5. Webhook: status="completed"             |
 |<---------------------------------------------|
 |                                              |
 | 6. GET /verifications/{request_id}           |
 |--------------------------------------------->|
 |                                              |
 |     200 OK { full structured report }        |
 |<---------------------------------------------|
 |                                              |
 | 7. GET /verifications/{request_id}/report.pdf|
 |--------------------------------------------->|
 |                                              |
 |     200 OK (signed PDF artefact)             |
 |<---------------------------------------------|
 |                                              |
 | 8. Update LOS: legal_status, disbursal_gate  |

Steps 1-2 trigger. Steps 3-5 are status webhooks the LOS listens for. Step 6 pulls the structured JSON the LOS writes back into its tables. Step 7 fetches the signed PDF for audit. Step 8 updates the loan record with derived fields downstream systems read from.

Payload structure: the request

The minimum viable verification request must carry property details, applicant details, document references, and metadata for routing. A typical request body:

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

Fields that earn their keep:

• tier_hint lets the verification service route to the right SLA tier without re-deriving it.
• fetch_required indicates the LOS does not have the document and is delegating retrieval — common in AP, TS, KA, MH where portal EC is reliable.
• idempotency_key stops a retry from creating a duplicate verification when the network drops between POST and 201.
• sha256 hashes pin the exact version of each document — critical for audit two years later.

Payload structure: the response

The response is where most LOS integrations under-invest. A PDF-only response wastes 80% of the value. The structured response should let the LOS gate disbursal on machine-readable fields. A minimum useful schema:

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

The fields the LOS must absolutely capture for downstream automation:

1. verdict — clear / conditional / rejected. This is the disbursal gate.
2. verdict_confidence — useful for credit committee dashboards. Low-confidence clears should route for review.
3. active_charges — non-zero means there is a live lien that must be cleared before disbursal.
4. ec_validity_from and ec_validity_to — the LOS audit log needs both. Many LOSs only store EC date, which is insufficient.
5. litigation_flag / lis_pendens_flag — boolean gates that should auto-route to the legal officer queue regardless of verdict.
6. mutation_complete — non-true blocks disbursal until mutation is closed.
7. marketability.conditions — array of conditions for conditional verdicts. Each condition must be tracked as a separate to-close item in the LOS.
8. panel_advocate.bar_number — needed for audit. Many LOSs miss this and the panel attestation becomes harder to defend later.

For a deeper look at what each of these fields actually means in legal terms, see our references on encumbrance certificates, 13-year vs 30-year title chain verification, and the legal opinion format.

Idempotency, retries, and webhook reliability

This is the part most LOS integrations get wrong on the first cut.

1. Idempotency keys on every POST: A POST with the same idempotency key, within a 24-hour window, must return the same request_id. Without this, a retry on flaky network creates a duplicate verification — and a duplicate panel advocate fee.
2. Exponential backoff on retries: Both LOS-to-service and service-to-LOS webhook retries should use exponential backoff with jitter (e.g., 1s, 2s, 4s, 8s, 16s, 30s, capped). Tight retry loops in production cause cascading failures.
3. Signed webhook payloads: Every webhook should be signed with an HMAC using a shared secret. The LOS must verify the signature before processing. Unsigned webhooks are a known attack surface.
4. Replay protection: Include a timestamp and a nonce in each webhook. Reject webhooks more than 5 minutes old or with a previously seen nonce.
5. Webhook acknowledgement contract: The LOS must respond 200 within 5 seconds for a webhook to count as delivered. Anything else triggers retry. Do business processing async on the LOS side.
6. Status reconciliation job: A nightly job should query the verification service for any request_id in a non-terminal state on the LOS and reconcile. Webhooks fail; reconciliation catches the gap.

Common LOS vendors in India

On-prem legacy stacks almost always need middleware between the LOS and any external verification API. Cloud-native LOSs can consume webhooks directly. The contract — request schema, response schema, webhook events, idempotency rules — is what you negotiate; the wiring is secondary.

Security considerations

Property verification APIs handle PII (PAN, applicant name), property identifiers, and signed legal documents. Bank security teams will (rightly) want these in place:

1. mTLS for outbound calls from the LOS: Client certificate authentication on top of HTTPS. Standard for inter-bank API traffic.
2. Field-level encryption for PII: PAN, applicant name, phone — encrypted at rest, decrypted only on entitled access.
3. Document URIs as signed, time-bound URLs: Pre-signed URLs that expire in 1-4 hours, not raw bucket paths.
4. Audit log of every API call: Request ID, timestamp, response code, latency. Pushed to the bank's SIEM, not just the verification service's logs.
5. RBAC on the verification service side: Lender-A's request can never be returned to Lender-B. Multi-tenant isolation must be testable.
6. Data residency: For Indian lenders, data should stay within Indian data centres. This is a procurement requirement at most banks now.
7. Right-to-erasure flow: For applications that don't proceed to disbursal, a documented data-purge path. Most Indian banks haven't formalised this yet, but it is coming.

LegiScore's verification API supports all of the above out of the box — webhook-driven async with HMAC signing, idempotency keys, structured JSON response with the full field set listed above, signed PDFs for audit, mTLS support, and Indian data residency. For a fuller picture of how this fits alongside manual workflows, see our piece on AI property verification vs manual due diligence.

Where most LOS integrations break

1. PDF-only response: LOS stores the report as an attachment and rekeys the verdict manually. Disbursal gating becomes a person, not a system.
2. No idempotency keys: Flaky network creates duplicate verifications. Finance team finds out in the month-end vendor invoice.
3. No structured conditions array: Conditional verdicts get treated like cleared verdicts because nobody parsed conditions out.
4. Webhook listener with no signature verification: Eventually exploited. Always sign webhooks.
5. No reconciliation job: Files silently stay in processing because their completion webhook was dropped.
6. Missing mutation_complete gate: Disbursal goes through on properties where mutation is still pending — surfaces during the next property mutation cycle.

What to scope for the next integration sprint

1. Define the request and response schema with version pinning.
2. Build the idempotent POST, signed webhook listener, structured GET, and PDF fetch.
3. Wire verdict, active_charges, litigation_flag, lis_pendens_flag, mutation_complete, and the conditions array into the disbursal gate.
4. Add the reconciliation job and put it on the on-call dashboard.
5. Pin every document by SHA-256 in the request and store evidence URIs on the LOS side.
6. Run a 2-week shadow mode where verification runs in parallel with the manual workflow before flipping the disbursal gate.

FAQ

Where should property verification sit in the LOS funnel? After sanction-in-principle and technical valuation, before final credit committee approval and disbursal. Earlier wastes legal cost on files that may not sanction; after disbursal is the worst outcome because legal defects surface when the money is already out. A well-integrated LOS triggers verification automatically once property documents and technical valuation are both complete.

Is webhook-driven integration better than status polling? For most modern LOSs, yes. Webhooks are lower-latency, lower-infra-cost, and easier to scale. Status polling is acceptable for legacy LOSs that cannot easily expose a public listener endpoint, but the polling intervals must be tuned carefully — too tight and the verification service rate-limits; too loose and the LOS lags real-time status. Webhooks plus a nightly reconciliation job is the modern standard.

What fields must the LOS capture from the verification response? At minimum: verdict (clear/conditional/rejected), active charge count, EC validity dates, litigation and lis pendens flags, mutation completion status, marketability conditions array, panel advocate name and bar number, and the signed PDF URI. These fields are what allow the LOS to automate disbursal gating instead of relying on a human to read a PDF and rekey decisions.

How do you handle idempotency for retries? Every verification POST should carry an idempotency_key that is unique per logical attempt (typically the lender reference ID + version). The verification service must, for some window (usually 24 hours), return the same request_id for the same key. This prevents network-retry duplicates that would otherwise create duplicate verifications and duplicate vendor fees.

What security standards should the verification API meet? mTLS for inter-system calls, HMAC-signed webhooks with replay protection, pre-signed time-bound document URIs, field-level encryption for PII, lender-tenant isolation with documented controls, Indian data residency, and a documented data-purge path for applications that do not proceed to disbursal. These are increasingly procurement requirements at Indian banks, not optional.

---

For broader context on how property verification fits into bank requirements, see our companion guides.