Skip to content
by Rakesh Waghela

16.1 Pre-application diligence

The full application takes a borrower 15 – 40 minutes and triggers vendor costs (bureau, KYC, AA fetch) on the lender side. Pre-application diligence is the soft-check layer that runs in < 2 minutes and decides whether to proceed.

Done well, pre-application diligence:

  • Filters out ineligibles early — borrower doesn’t waste time, lender doesn’t burn vendor cost.
  • Sets borrower expectations — borrower knows if they’re likely to qualify and at what indicative terms.
  • Captures channel attribution cleanly — DSA / CA / partner credit captured at first touch.
  • Provides indicative offers — borrower gets a directional “yes you may qualify for ₹X – ₹Y” before committing to full application.
  • Pre-screens for fraud signals — multiple recent attempts, suspicious patterns.

What pre-application diligence checks

Section titled “What pre-application diligence checks”

A. Identifier validation

Section titled “A. Identifier validation”
  • PAN format — basic format check (10 chars, 5+4+1 pattern).
  • Mobile — format + carrier validation.
  • GSTIN format — 15-char pattern; state-code prefix valid.
  • PAN-mobile linkage (where allowed) — light cross-check.

B. Pre-eligibility soft signals

Section titled “B. Pre-eligibility soft signals”
  • GST registration active (single API call to verify GSTIN status).
  • Business vintage estimated from GST registration date or claimed.
  • Industry not on negative list (NIC code check).
  • Geography in service area.
  • Soft bureau pull where supported (some CICs offer soft-pull APIs that don’t show as full enquiries; for those, indicative bureau view possible).
  • AA pre-eligibility with a 1-month consent for soft check (very rare; mostly skipped).

C. Dedup and velocity

Section titled “C. Dedup and velocity”
  • Dedup on PAN / mobile / GSTIN — flag if borrower has applied recently.
  • Velocity check — too many applications from same device / IP / channel in a short window.
  • Internal blacklist hit.

D. Channel and attribution capture

Section titled “D. Channel and attribution capture”
  • UTM parameters captured.
  • DSA / CA / partner attribution.
  • Campaign reference if applicable.

E. Indicative offer (where data permits)

Section titled “E. Indicative offer (where data permits)”
  • A directional “you may qualify for ₹X – ₹Y at indicative rate” — labelled clearly as not a sanction.
  • Set borrower expectation; reduce abandonment later.

F. Borrower-stated intent capture

Section titled “F. Borrower-stated intent capture”
  • Loan amount sought.
  • Purpose (working capital / inventory / expansion / specific).
  • Tenure preference.

What pre-application diligence does NOT do

Section titled “What pre-application diligence does NOT do”
  • No hard bureau pull (would burn fee + record enquiry on borrower’s bureau).
  • No commercial bureau pull.
  • No AA consent flow (deferred to application).
  • No vendor KYC charges (deferred).
  • No formal decision — pre-eligibility is indicative only; full application can return different outcome.

Architecture

Section titled “Architecture”
Borrower lands on portal / app / DSA portal
                │
                ▼
        Pre-app form (5-7 fields)
                │
                ▼
   [Pre-app service]
        │
        ├── Format validators (PAN, mobile, GSTIN)
        ├── GSTIN status API (Karza/Signzy/GSP)
        ├── NIC code check (negative list)
        ├── Geography check (service area)
        ├── Internal dedup
        ├── Velocity check (device + IP + channel)
        ├── Soft bureau pull (if supported)
        ├── Channel attribution capture
                │
                ▼
        Pre-eligibility verdict
        ├── Pass + indicative offer
        ├── Conditional (proceed but with caveat)
        └── Decline (hard cuts failed)
                │
                ▼
        If pass: redirect to full application
        If decline: clear reason, suggest next steps

Pre-application API

Section titled “Pre-application API”
  • POST /v1/pre-eligibility/check
Request:
{
  "mobile": "+91XXXXXXXXXX",
  "pan": "ABCDE1234F",
  "gstin": "29ABCDE1234F1Z5",
  "loan_amount_sought": 2500000,
  "tenure_sought_days": 90,
  "channel": "ca_portal",
  "channel_partner_ref": "ca_firm_id_123",
  "consent": {
    "soft_bureau_pull": true,
    "purpose_aware": true
  }
}
Response (pre-eligible):
{
  "pre_eligibility_id": "pe_xyz123",
  "verdict": "pre_eligible",
  "indicative_offer": {
    "amount_range": "1500000-3500000",
    "rate_range": "0.195-0.225",
    "tenure_max_days": 180
  },
  "next_step": {
    "action": "start_application",
    "url": "/applications/start?pre_eligibility=pe_xyz123"
  },
  "checks": {
    "gstin_active": true,
    "industry_eligible": true,
    "geography_serviceable": true,
    "dedup_clean": true,
    "internal_blacklist_clean": true,
    "soft_bureau_indicative": "good"
  }
}
Response (declined):
{
  "pre_eligibility_id": "pe_abc456",
  "verdict": "declined",
  "reason_code": "GSTIN_CANCELLED",
  "reason_borrower_facing": "We're unable to proceed as your GSTIN is currently inactive. Please address this with the GST authority and re-apply.",
  "checks": {
    "gstin_active": false,
    "..." : "..."
  }
}

Cost economics

Section titled “Cost economics”

Per pre-eligibility check:

ItemCost (illustrative)
GSTIN status check₹1 – ₹3
Internal dedup / velocity~₹0 (own data)
Soft bureau pull (if supported)₹5 – ₹20
Negative-list lookup~₹0
Total per check~₹10 – ₹25

vs full application data ingestion: ~₹150 – ₹400 per borrower.

Filtering 30 – 50% of leads at pre-app via soft-screen typically pays back the pre-app cost many times over.

Section titled “Data and consent capture”

Pre-application data is personal data under DPDP — even the soft pulls need:

  • Explicit consent at pre-eligibility screen for each data point sought.
  • Purpose disclosure — “to assess if you may qualify”.
  • Retention limit — typically 90 days if borrower doesn’t proceed.
  • Deletion on request — borrower can request deletion.

The platform must:

  • Capture consent at this stage with timestamp + IP + device.
  • Treat the pre-eligibility data with same security as application data (PII tokenisation).
  • Honour retention limits — auto-purge unconverted pre-eligibility records.

Indicative-offer ethics

Section titled “Indicative-offer ethics”

Setting borrower expectation matters. Indicative offers should:

  • Be clearly labelled as indicative, not sanction.
  • Use realistic ranges, not the absolute maximum.
  • Communicate that full application may return different outcome.
  • Reference the specific data the indicative was based on.

Misleading indicative offers (showing a higher amount than realistic) are a Fair Practices Code issue and damage trust.

Behavioural metrics to track

Section titled “Behavioural metrics to track”
  • Pre-app to application conversion: 30 – 60% typical; below 20% suggests pre-app is too liberal (decline-at-full-app too late) or too restrictive (declining good borrowers).
  • Indicative-vs-actual offer gap: if actual sanction is < 50% of indicative max consistently, indicative is too generous.
  • Pre-app decline reasons distribution: GSTIN-cancelled, geography, NIC code, dedup, velocity — guides product / channel decisions.
  • Per-channel conversion: helps identify channels with poor lead quality.

Channels and pre-app

Section titled “Channels and pre-app”
ChannelPre-app behaviour
Direct (borrower portal)Standard pre-app; borrower sees indicative offer
DSA portalDSA sees pre-eligibility verdict; presents to borrower
CA portalCA pre-screens client’s eligibility before formal referral
Anchor portalAnchor’s vendor sees pre-eligibility; mass-screen possible
Embedded (Tally / accounting partner)Partner triggers pre-app via API; result displayed within partner UI

For each channel, the pre-app UX and the indicative-offer ethics differ slightly; channels with intermediaries (DSA / CA / anchor) need clear separation between “the lender’s pre-eligibility view” and “the intermediary’s interpretation”.

Edge cases

Section titled “Edge cases”
  • Borrower pre-eligible but DSA still pushes application that gets declined at full — DSA training; conversion-rate tracking.
  • Indicative offer screenshot-shared — borrower keeps showing the indicative offer expecting it as a sanction. Communication discipline + KFS clearly different.
  • Same borrower applies via multiple channels in 24 hours — dedup; attribution conflict resolved by policy (first-touch / last-touch / channel-priority).
  • Pre-app declined but borrower remediates (e.g., reactivates GSTIN, registers Udyam) — re-pre-app and proceed.
Section titled “Related”