Employment Verification Letter Fraud: When the Employer Can’t Be Reached

A candidate’s past-employment check has been open for nine days. The previous employer has not answered two emails, the HR phone number on the letter goes to voicemail, and the client wants the report by Friday. The candidate has uploaded an employment verification letter on company letterhead: dates of employment, designation, a signature, a stamp. It looks right. The question on the reviewer’s desk is whether the letter can carry the check until the employer responds, or whether it has to wait.

That question has two parts. Is what the letter says true? Only the employer can answer that. Is this file the one the employer issued, or has it been opened and changed since? The file itself can sometimes answer that. A visual review of the letter answers neither reliably.

How an employment letter gets verified today

Background verification (BGV) of past employment rests on one principle: confirm the claim with the source, not with the paper the candidate supplied. The channel differs by market.

• United States. Many US verifiers check The Work Number, an Equifax-operated database of employment and income data contributed by employers and payroll providers. Where an employer is not in the database, the verifier contacts the employer directly.
• India. Verifiers contact the previous employer’s HR team by email or phone, and often cross-check against the candidate’s EPF records: the EPFO service history linked to a UAN lists each establishment with its date of joining and, where the employer has recorded one, the date of exit. The candidate holds that login, so the service history often arrives as a screenshot or download alongside the letters.
• United Kingdom and EU. The reference request to the previous employer is the core of the check. In the UK an employer does not usually have to give a reference, except under a written agreement or in a regulated industry such as financial services, and a reference can be brief: job title, salary and dates. Practice across the EU varies by country and employer, but the pattern is the same: ask the employer.

Alongside the employer channel, a reviewer reads the letter itself: letterhead, signature, stamp, whether the dates line up with the CV. That visual review is useful.

Where the channel has no file step

None of these channels opens the PDF as a file. Employer contact and database lookups confirm the claim; visual review checks what the page shows.

Most of the time that does not matter, because the employer answers. It matters when:

• The employer has closed, merged or been acquired, and nobody holds the old records.
• The employer is a small firm with no HR desk, and emails go unanswered.
• The HR contact on the letter was supplied by the candidate, so the confirmation channel is not independent.
• Turnaround pressure pushes a case to close on documents while employer confirmation is still pending.

In all four, the letter carries more weight than it was designed to. That is the window where a file-level check is worth having.

Three kinds of problem letter

Three patterns come up with employment, experience and relieving letters:

1. A genuine letter, changed. The employer really issued it; the candidate later changed the joining date, the exit date or the designation. The letterhead and signature are real because the document is real.
2. A letter written from scratch. No employer ever issued it. It was typed up, often with a lifted logo.
3. Several letters in one upload. An experience letter, a relieving letter and a payslip combined into a single PDF, sometimes with one page swapped for a page from another file.

A structural check reacts differently to each. A genuine letter that was edited after it was issued can carry evidence of that later write, and comes back modified with named modification markers. A fabricated letter is a content problem: whether it says something false is a question for the employer, not for the file. A combined upload is not the file any employer issued. It usually comes back modified, sometimes inconclusive. Whatever the result, ask the candidate for each letter as it was issued.

The fake experience letter detection page covers this from the document-type side, including the experience verification letter and the verification of work experience letter. Relieving letters have their own page.

Complementary, not a substitute

A structural check tells you something about the file. It does not tell you whether the candidate worked there, in that role, for those dates. HTPBE? does not read the letter’s content, does not check names, dates or salaries, and does not contact anyone. A letter can come back intact and still state a false title, because intact describes the file, not the claim.

The three verdicts, read in a BGV workflow:

• modified. The check found evidence that the file was changed after it was created. That is a finding about the file, not a finding of fraud. Legitimate steps after generation, such as stamping or re-saving by a document system or upload portal, can also register as modification. The routing is simple: do not accept the letter on the document alone, and push it to employer confirmation.
• inconclusive. The check could not establish the file’s provenance. The reason is in status_reason. Letters from small employers can land here. It is not a finding against the candidate, and it does not clear the letter either: the file cannot carry the evidence, so employer contact stays primary. One value, analysis_incomplete, describes the check rather than the document: resubmit the file, and if it keeps returning that, treat the letter as unverified, not clean. We cover the full picture in what inconclusive means.
• intact. No evidence of modification after creation was found. It is the absence of one kind of evidence, not confirmation that the employment happened.

The result tells you which letters must not carry the check by themselves. It does not tell you which candidates to reject, and it should never be used that way.

Adding the check to a BGV pipeline

Run the check at intake: each uploaded letter goes through when the case opens, while the employer request is still out. By the time an operations lead decides whether a case can close on documents, the result is already on the file.

Integration is one POST and one GET. Submit the document URL:

curl -X POST https://api.htpbe.tech/v1/analyze \
  -H "Authorization: Bearer $HTPBE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://files.example.com/cases/4821/experience-letter.pdf"}'

The response carries a check id. Fetch the result with GET https://api.htpbe.tech/v1/result/{id}. A trimmed inconclusive result looks like this:

{
  "status": "inconclusive",
  "status_reason": "consumer_software_origin",
  "modification_markers": [],
  "usage_caution": {
    "safe_for_automated_adverse_decision": false,
    "recommended_action": "request_from_issuer",
    "message": "..."
  }
}

Route on usage_caution.recommended_action, which maps directly onto the BGV decision:

• route_to_human_review (on modified): a reviewer looks at the case with the marker list attached; the letter does not close the check without employer confirmation.
• request_from_issuer (on inconclusive): the case waits for employer confirmation rather than closing on the document.
• no_action (on intact): no modification evidence was found; the employer check proceeds as normal.

safe_for_automated_adverse_decision is always false. The verdict is an input to routing, not a decision about a person.

Test keys (htpbe_test_*) return synthetic, deterministic results for a fixed set of test URLs, so you can build every routing branch before a real candidate document goes through. If you want to try a single letter by hand first, the web upload gives five checks on signup, then pay-per-check.

For more on the payslip side of the same workflow, see payslip fraud detection for HR teams. The employment letter detection hub lists every letter type we cover.

Where it fits

Employer contact and database lookups remain the verification. A structural check does not replace them and does not try to. It adds a sorting step for the window when the employer has not answered, or will not answer: which letters can wait, and which must not be accepted on paper alone.

API documentation, test keys and plans are on the API page.