\u201cI work at a large IT company, \u20b985,000 a month.\u201d 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.<\/p>\n\n\n\n
There is a harder record to fake: the trail of provident fund contributions that formal employment leaves <\/a>at the EPFO, indexed by the employee\u2019s Universal Account Number (UAN). Contributions arrive monthly from the employer\u2019s 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.<\/p>\n\n\n\n A UAN verification API validates a person\u2019s employment claims against EPFO<\/a> records anchored to their Universal Account Number, the portable, lifelong account number that links an employee\u2019s provident fund memberships across employers.<\/p>\n\n\n\n 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\u2019s name, and fetching employment history for the establishments (employers) attached to the UAN, with joining\/exit dates and contribution activity.<\/p>\n\n\n\n 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 \u201csource over document\u201d principle that runs through this entire verification series, applied to the claim that fraud targets most: income.<\/p>\n\n\n\n Read properly, UAN-linked data answers four underwriting questions.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Is the claimed salary plausible? Contribution amounts derive from PF wages, which relate to (though do not equal) actual salary. Contributions consistent with a \u20b925,000 wage base sit awkwardly under an \u20b985,000 income claim, flagging the file for the deeper income verification that our [bank statement analysis<\/a>] and rails provide.<\/p>\n\n\n\n The composite is a fraud filter<\/a> and a stability profile in one pull, which is why the UAN check increasingly runs early in salaried-lending funnels, before costlier verification spends.<\/p>\n\n\n\n Production flows follow a consent-first pattern in four steps.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The API confirms the UAN exists and returns the registered holder details, which are fuzzy-matched against the applicant\u2019s verified identity. A UAN belonging to someone else borrowed employment identity fails here.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Salary-advance and earned-wage products. Products whose entire premise is active employment use contribution recency as a live eligibility signal.<\/p>\n\n\n\n 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<\/a>].<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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<\/a>] describes, with human verification reserved for gaps and informal-sector claims.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Insurance and underwriting adjacent. Employment stability features feed persistency and risk models where occupation and income claims matter.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Four limits define the rail\u2019s honest boundaries.<\/p>\n\n\n\nWhat Is a UAN Verification API?<\/strong><\/h2>\n\n\n\n
What EPFO Data Reveals: Employment, Tenure, Stability<\/strong><\/h2>\n\n\n\n
How UAN Verification Flows Work<\/strong><\/h2>\n\n\n\n
Step 1: Identifier Capture and Consent<\/strong><\/h3>\n\n\n\n
Step 2: UAN Validation and Name Match<\/strong><\/h3>\n\n\n\n
Step 3: Employment History Fetch<\/strong><\/h3>\n\n\n\n
Step 4: Signal Extraction and Decision<\/strong><\/h3>\n\n\n\n
Lending Use Cases: The Salaried-Borrower Stack<\/strong><\/h2>\n\n\n\n
Beyond Lending: BGV and Platform Onboarding<\/strong><\/h2>\n\n\n\n
Limits of EPFO Data and How to Design Around Them<\/strong><\/h2>\n\n\n\n