“I work at a large IT company, ₹85,000 a month.” Every lender hears versions of this claim thousands of times a day, and the traditional evidence for it salary slips and HR letters can be produced by any laptop with a template. Payroll document fraud is not sophisticated; it does not need to be, because most verification of it is visual.
There is a harder record to fake: the trail of provident fund contributions that formal employment leaves at the EPFO, indexed by the employee’s Universal Account Number (UAN). Contributions arrive monthly from the employer’s compliance systems, establishment by establishment, month by month. A UAN verification API turns that trail into an underwriting and screening input. This guide explains what the UAN reveals, how verification flows work, and where EPFO data fits and does not fit in income assessment.
What Is a UAN Verification API?
A UAN verification API validates a person’s employment claims against EPFO records anchored to their Universal Account Number, the portable, lifelong account number that links an employee’s provident fund memberships across employers.
Depending on the integration mode and consent, the API family covers several operations: resolving a UAN from identifiers such as mobile or PAN, validating that a UAN exists and matches the claimed holder’s name, and fetching employment history for the establishments (employers) attached to the UAN, with joining/exit dates and contribution activity.
The evidentiary logic is what makes this rail valuable. Provident fund contributions are statutory filings made by employers, not documents supplied by applicants. A twelve-month contribution streak from a named establishment is third-party, regulatorily anchored evidence of employment, the same “source over document” principle that runs through this entire verification series, applied to the claim that fraud targets most: income.
What EPFO Data Reveals: Employment, Tenure, Stability
Read properly, UAN-linked data answers four underwriting questions.
Is the person formally employed now? Active, recent contributions from a current establishment confirm formal employment; the binary claim of salary slips cannot prove it.
By whom, and since when? Establishment names and joining dates verify the stated employer and tenure. An applicant claiming five years at a company whose EPFO linkage began four months ago has some explaining to do.
How stable is the employment history? The sequence of establishments and gaps between exits and joinings sketches job stability; frequent short stints and long unexplained gaps are a warning signal, not a disqualification.
Is the claimed salary plausible? Contribution amounts derive from PF wages, which relate to (though do not equal) actual salary. Contributions consistent with a â‚ą25,000 wage base sit awkwardly under an â‚ą85,000 income claim, flagging the file for the deeper income verification that our [bank statement analysis] and rails provide.
The composite is a fraud filter and a stability profile in one pull, which is why the UAN check increasingly runs early in salaried-lending funnels, before costlier verification spends.
How UAN Verification Flows Work
Production flows follow a consent-first pattern in four steps.
Step 1: Identifier Capture and Consent
The applicant provides their UAN, or the flow resolves it from mobile/PAN where supported, alongside explicit consent for employment verification. Consent capture here is not ceremonial: employment data is personal data, and the DPDP-grade audit trail starts at this step.
Step 2: UAN Validation and Name Match
The API confirms the UAN exists and returns the registered holder details, which are fuzzy-matched against the applicant’s verified identity. A UAN belonging to someone else borrowed employment identity fails here.
Step 3: Employment History Fetch
With consent, the flow retrieves establishment history and contribution activity. OTP-based flows to the UAN-linked mobile provide the strongest consent binding, at some conversion cost; design the fallback path deliberately.
Step 4: Signal Extraction and Decision
Raw history converts to decision features: current-employment flag, current-employer name match against the application, tenure, contribution recency and continuity, and wage-base plausibility versus claimed income. Features feed the credit policy; the raw response is archived as evidence.
Lending Use Cases: The Salaried-Borrower Stack
Personal loans and credit cards. The UAN check verifies the employment premise of the application in seconds. Employer name mismatches, dead contribution trails, and tenure inflation surface before bureau pulls and statement analysis incur their cost.
Salary-advance and earned-wage products. Products whose entire premise is active employment use contribution recency as a live eligibility signal.
Income corroboration. UAN wage-base signals triangulate with bank-credit patterns and ITR data into an income confidence score three independent sources that fraud must defeat simultaneously, a materially harder problem than forging one document. This triangulation is the practical answer to the payroll-forgery patterns we documented in [first-party fraud in India].
Employer-risk overlays. Lenders maintaining employer-level risk views (delinquency by employer, establishment health) key those overlays to verified EPFO establishment identities rather than free-text employer names, cleaning a notoriously dirty data field.
Beyond Lending: BGV and Platform Onboarding
Background verification. Employment-history checks are the slowest, most expensive leg of traditional BGV calls to HR departments, with weeks of waiting. UAN-anchored history compresses the formal-sector portion to an API call inside the stack our [background verification API guide] describes, with human verification reserved for gaps and informal-sector claims.
Gig and platform onboarding. Platforms verifying that a would-be borrower or partner holds (or recently held) formal employment use the same rail for eligibility and risk tiering.
Insurance and underwriting adjacent. Employment stability features feed persistency and risk models where occupation and income claims matter.
Tenant and high-trust screening. Where lawful basis and consent exist, employment verification supports high-commitment relationship checks, always purpose-bound and always consented to.
Limits of EPFO Data and How to Design Around Them
Four limits define the rail’s honest boundaries.
Formal-sector coverage only. EPFO coverage applies to establishments within the EPF Act’s ambit; informal workers, many gig workers, most self-employed, and some exempt establishments sit outside it. Absence of EPFO history is not an absence of income; route these applicants to the [bank statement and ITR rails] rather than declining on a null.
Wage base is not salary. PF contributions are calculated on PF wages, frequently capped or structured below gross salary. Use contribution signals for plausibility bands, never as an income figure.
Filing lag. Employer filings run on statutory cycles; the most recent month or two may legitimately show as pending. Recency thresholds must absorb normal lag.
Exempt trusts and edge structures. Some large employers run exempted PF trusts with different data visibility. Establishment-level nulls need review routing, not auto-decisions.
Designed around these limits as one triangulation source among three, with null-handling and lag tolerance, the UAN rail adds a layer of employment truth that document-based verification never offered.
Key Takeaways
- A UAN verification API validates employment claims against EPFO contribution records, statutory, and employer-filed evidence that salary-slip forgery cannot touch.
- One pull answers four questions: employed now, by whom and since when, how stable, and whether claimed income is plausible.
- Consent-first flows with name matching against verified identity to defeat borrowed-UAN fraud and satisfy DPDP discipline.
- In lending, UAN signals run early, cheap fraud filtering before bureau and statement spends, and triangulate with bank and ITR data for income confidence.
- EPFO’s limits (formal-sector scope, wage-base ≠salary, filing lag) define routing rules, not disqualification: nulls go to alternate income rails.
Frequently Asked Questions
Is consent required for a UAN verification API check?
Yes. Employment data is personal data, and UAN verification API flows should capture explicit, purpose-bound consent, ideally OTP-bound to the UAN-linked mobile, with the consent record retained as part of the verification evidence under DPDP obligations.
What happens when an applicant has no EPFO record in a UAN verification API check?
A null result means the person sits outside formal EPFO coverage, common for gig, informal, and self-employed applicants, not that they lack income. Well-designed flows route these cases to alternate income verification rails instead of declining.
How does a UAN verification API help lenders?
A UAN verification API verifies the employment premise of a loan application at source: current employer, tenure, contribution continuity, and wage-based plausibility versus claimed income, filtering payroll-document fraud before costlier verification steps run.
Can a UAN verification API confirm exact salary?
No. A UAN verification API surfaces contribution- and wage-based signals, which support plausibility checks rather than exact income. Pair it with bank statement analysis and ITR verification for income precision.
What is a UAN verification API? here
A UAN verification API validates a person’s Universal Account Number against EPFO records, confirming the UAN’s existence and holder identity and, with consent, retrieving employment history, establishment names, tenure, and contribution activity.
Conclusion
Income fraud persists because income evidence was always the applicant’s to manufacture. The UAN rail inverts that: the evidence is filed by employers, held by a statutory body, and accumulated month by month over years a record that a template cannot counterfeit and a desperate applicant cannot backfill.
The larger pattern is triangulation. EPFO, bank statements via account aggregators, and tax records are converging into a three-source income truth layer for Indian lending. Each source alone has gaps; together, they leave fraud very little room. Lenders assembling that layer are now building the underwriting advantage of the next credit cycle.
