PDF Security Blog

H-1B Salary Slip Fraud Detection: Altered Indian Payslips at the Offer Stage

HTPBE Team··8 min read
H-1B Salary Slip Fraud Detection: Altered Indian Payslips at the Offer Stage

This article is a snapshot — content was accurate as of May 2026 (code examples tested against the API as of May 2026). The product evolves actively; specific counts, examples, and detection rules may have changed since publication — see the changelog for the current state.

A mid-sized US fintech company extends an offer to a senior engineer based in Bangalore. The candidate submits three months of payslips from their current employer — a well-known Indian IT services firm — showing a monthly CTC of ₹18 lakhs. The offer is set accordingly. Three weeks later, during background screening, the BGV vendor contacts the employer and receives no response. The candidate explains that Indian companies routinely ignore BGV inquiries and submits an employment confirmation letter instead.

The actual salary on those payslips was ₹11 lakhs. The candidate had opened the PDFs in a browser-based editor, changed the compensation figures, and re-exported them. Everything else — the employer letterhead, the PF deductions, the company logo — was authentic.

This is the dominant salary fraud vector in Indian-to-US hiring pipelines. H-1B salary slip fraud detection is not part of most offer workflows.

Why H-1B Salary Slip Fraud Detection Fails in Standard BGV Workflows

Indian background screening has a structural gap that enables document fraud: employer non-response rates on employment and compensation fraud detection routinely run between 15% and 30%, according to data from major BGV vendors. Indian employers — particularly mid-size IT services companies and startups — frequently do not maintain dedicated BGV response teams. HR contacts leave. Emails go unanswered for weeks.

When a BGV vendor cannot confirm compensation, the candidate is typically asked to provide supporting documentation: payslips, an offer letter, or a compensation certificate. This is a reasonable fallback. It is also the point where document fraud enters the workflow.

The candidate already has their real payslips. They know the exact format, the correct deductions line, the PF and ESI structure. Editing the compensation figure and re-exporting takes under ten minutes. The resulting document looks identical to a genuine payslip because it is a genuine payslip — with one number changed.

US immigration counsel reviewing documents for H-1B prevailing wage compliance, and HR teams calibrating offers against claimed compensation, work from those figures. If the underlying documents have been altered, the entire wage analysis is based on false data.

What the Altered Payslip Actually Contains

Indian payroll is dominated by a small number of software platforms: Keka, GreytHR, Darwinbox, Zoho Payroll, and SAP SuccessFactors for larger enterprises. Each platform generates PDFs with a recognizable structural signature — a specific Producer value, a single-pass xref structure, and metadata that reflects an automated document generation event rather than a manual save.

When a candidate downloads their genuine payslip and opens it in a PDF editor — Adobe Acrobat, Foxit, Smallpdf, ILovePDF, or even a browser’s built-in save-as function — the editing software appends its own changes to the file. In most cases it writes its own name into the Producer field. It adds a new cross-reference entry recording the edit session. It updates the modification timestamp.

The result is a file that claims to have been generated by Keka or GreytHR — because the original producer metadata is still present in the file’s early sections — but also carries a second production record from the editing tool. The modification timestamp is later than the document’s claimed issuance date. The edit history shows at least two sessions: the original payroll generation and the candidate’s edit.

None of this is visible when you open the PDF. It is preserved in the file’s internal structure.

What HTPBE? Detects

When a salary slip with this edit pattern is submitted through HTPBE?, the analysis reads those structural layers and returns a verdict based on what the file itself recorded.

A realistic API response for an altered Indian payslip:

{
  "id": "ck_7e2a91f4-bc34-4d7e-a108-3f5c8e012bd9",
  "status": "modified",
  "modification_confidence": "high",
  "modification_markers": [
    "PRODUCER_MISMATCH",
    "INCREMENTAL_UPDATES",
    "DIFFERENT_DATES"
  ],
  "creator": "Keka HR",
  "producer": "Smallpdf",
  "creation_date": 1738368000,
  "modification_date": 1745712000,
  "xref_count": 3
}

Three signals are present in this response:

PRODUCER_MISMATCH — The file’s internal records name two different software systems. Keka HR generated the original document. Smallpdf processed it afterward. Payroll software does not send finished payslips through Smallpdf. The mismatch indicates the file was reopened in a different tool after initial generation.

INCREMENTAL_UPDATES — Three xref entries exist in the file. The first corresponds to the original payroll generation. The later entries record editing sessions. A genuine payslip from an automated payroll system has exactly one.

DIFFERENT_DATES — The modification timestamp is nearly three months after the creation date. A payslip generated once by a payroll system has matching creation and modification times. A gap of months indicates the file was opened and resaved long after it was originally issued.

Together, these markers produce a modified verdict. No comparison against an original is needed — the file’s own structure records what happened.

The INCONCLUSIVE Case: Small Employers and Word-Generated Slips

Not all Indian employers use structured payroll software. Many small and mid-size employers — boutique agencies, early-stage startups, family-owned businesses — generate payslips in Microsoft Word or Google Docs, export them to PDF, and send them by email. These documents have no institutional payroll metadata. They originate from consumer software.

For these files, HTPBE? returns inconclusive.

inconclusive is not a fraud flag. It means the document was created with consumer software, and there is no structural basis for checking whether it was modified after creation.

The correct interpretation depends on the context:

If the candidate works at a known large employer — Infosys, Wipro, TCS, HCL, Cognizant, or any company with structured payroll infrastructure — an inconclusive verdict on their payslip is a significant flag. Those companies use enterprise payroll systems. Their payslips do not originate in Word. Escalate to BGV.

If the candidate works at a small employer or consultancy where Word-generated slips are common, inconclusive alone does not indicate fraud. Combine it with other signals: Is the document’s visual layout consistent? Are the PF/ESI deduction calculations correct? Does the employer size match the claimed compensation band? Is there corroborating documentation?

The distinction matters in practice. Rejecting every inconclusive document in an Indian hiring pipeline would produce a high false-positive rate for candidates from smaller employers. The more defensible approach is to treat inconclusive as a signal that feeds a risk-scoring model, not as an automatic rejection.

How to Integrate This Into Your Offer and fraud-detection workflow

The right time to run this check is at the offer stage, before the compensation figure is finalized and before H-1B sponsorship documentation is started.

Step 1: Collect payslips as a URL or upload them to your document storage. HTPBE? analyzes PDFs by URL. When candidates submit payslips through your ATS portal or onboarding platform, generate a presigned URL from your document storage (S3, Azure Blob, Google Cloud Storage) and pass it to the API.

Step 2: Submit to HTPBE? and route on verdict.

curl -X POST https://api.htpbe.tech/v1/analyze \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://your-storage.example.com/candidates/12345/payslip-jan.pdf"}'

Step 3: Route based on the response.

def route_payslip(result: dict, employer_is_large: bool) -> str:
    status = result["status"]

    if status == "modified":
        # Structural evidence of post-creation edit — escalate immediately
        return "escalate_to_hr"

    if status == "inconclusive" and employer_is_large:
        # Large employer should not produce Word-origin payslips — escalate to BGV
        return "escalate_to_bgv"

    if status == "inconclusive":
        # Small employer context — flag for manual review, not auto-reject
        return "manual_review"

    # intact
    return "proceed"

Store the HTPBE? check ID alongside the candidate record. If a hiring decision is later challenged, the forensic report is retrievable from GET /api/v1/result/{check_id} and provides an auditable basis for the decision.

The Cross-Border Pattern: UK Tier 2 and Australian 482 Visas

The same structural fraud pattern appears in UK and Australian immigration workflows. Indian nationals applying for UK Skilled Worker visas (formerly Tier 2) and Australian Temporary Skill Shortage (subclass 482) visas must provide proof of current overseas earnings as part of the sponsorship and salary assessment process.

The incentive is identical: higher claimed current earnings support a stronger case for the role’s salary level and the visa’s skills threshold. The method is identical: genuine payslip, edited compensation figure, re-exported PDF.

UK Home Office and Australian Department of Home Affairs guidance both require sponsors to check that salary evidence is genuine. The structural forensic checks that detect this fraud pattern in US H-1B workflows apply directly to Tier 2 and 482 applications. If your organization sponsors visas across multiple jurisdictions, a single API integration covers all three workflows.

Who This Is For

US HR and talent acquisition teams processing Indian candidates for H-1B sponsorship or US-based offers where salary history informs the offer. Run HTPBE? at the document collection stage, before offer letters are finalized and before immigration counsel is engaged.

Background fraud detection vendors covering Indian employment. When primary-source fraud detection fails and the candidate provides supporting payslip documentation, forensic analysis is the check that BGV currently lacks. The fake salary slip detection page covers the full detection pattern for payslip fraud across geographies.

Immigration compliance teams and counsel reviewing compensation documentation for prevailing wage determinations and visa petitions. A modified verdict on a submitted payslip is a material fact for the record. Document it before the petition is filed, not after.

HR platforms and ATS vendors looking to add document integrity checks to their candidate fraud detection layer. The HR and hiring solutions page covers how HTPBE? integrates into recruiting workflows at the platform level.

The API is available on the Starter plan at $15/month. For BGV vendors and ATS platforms processing large volumes, the Growth and Pro plans support up to 1,500 checks per month.

Share This Article

Found this article helpful? Share it with others to spread knowledge about PDF security and fraud detection.

https://htpbe.tech/blog/h1b-indian-salary-slip-fraud

Secure your workflow

Create your account — API key on signup, free test environment on every plan.
From $15/mo. No sales call. Cancel any time.