Software

How Cloudhire Verifies Candidate Data: The Process Behind Every Claim on a Cloud-ID

The traditional employment verification call has been broken for at least a decade, and most of the staffing industry is still pretending it works.

Here is what actually happens when a hiring firm calls a candidate’s former employer to “verify employment.” The call goes to a general HR line. The HR representative who has never met the candidate, has no operational memory of the role, and is constrained by employer policy confirms two things: dates of employment, and last title held. Sometimes salary. They will not tell you whether the person was good. They will not tell you what the person actually did. They will not tell you whether the person was fired, asked to leave, or quit voluntarily. In most jurisdictions, employer counsel has trained them not to.

So the verification call confirms the skeleton that someone with this name worked at this company between these dates and confirms nothing about the substance of the claim. A candidate who worked as a junior support analyst for fourteen months can list themselves as a senior systems engineer for fourteen months, and the verification call will not catch it. The dates check out.

This is the gap Cloudhire’s verification process is built to close.

The Three-Layer Verification Model

Every claim on a Cloudhire candidate’s Cloud-ID is verified through one or more of three independent methods. Different claim types use different combinations. The principle is that no single source of truth is sufficient; every material fact has at least one corroborating signal, and where the stakes are high, three.

Layer 1: Peer attestation from verified company domains

This is the layer most resume verification systems do not even attempt, and it is the one that produces the strongest signal on what a candidate actually did versus what they claim.

For each role on a candidate’s record, we identify former colleagues, managers, peers, and direct reports who would have personal operational knowledge of the candidate’s actual work. The candidate provides initial contacts; we expand the list independently through public sources to reduce coaching risk. We then reach out and request attestation.

Here is where the verification has teeth: an attestation only counts if it comes from an email address on the verified corporate domain of the company in question. A former coworker confirming a candidate’s role at Acme Corp must do so from an @acmecorp.com address. Personal Gmail attestations do not enter the record. This single rule eliminates the most common attestation fraud, a friend of the candidate posing as a former colleague, because gaining write-access to a corporate email domain you do not actually work at is a non-trivial barrier.

Each attestation is structured. The colleague is asked to confirm specific operational facts: did the candidate work on this project, did they hold this title, did they report to this person, did they actually do the work they are claiming. Free-text comments are optional and stored, but the structured fields are what enter the verification record. We collect attestations from multiple sources for each role where possible, and where attestations conflict, the conflict is flagged on the candidate’s profile rather than silently resolved.

The result is a verification signal qualitatively different from “HR confirmed the dates.” It is operational confirmation from people who would actually know.

Layer 2: Document collection and AI-assisted authenticity analysis

The second layer is documentary. Candidates submit role-relevant documentation: offer letters, relieving letters, payroll records, tax documentation, project completion certificates, and, for engineering candidates, code contribution evidence where the work is non-confidential. Each document is processed through an AI verification pipeline that checks for the signatures of authenticity.

The pipeline does several things in parallel. It compares document formatting against the known templates used by the issuing company at the time of issue, including fonts, letterheads, signature blocks, and watermarks. It checks for digital tampering signatures: inconsistent metadata, mismatched compression artifacts, and layer artifacts left by editing software. It cross-references claimed entities, company addresses, registered office details, and executive signatures against public corporate records. And it flags documents that are statistically unusual for their claimed origin: an offer letter from a Fortune 500 company that does not match any known offer letter format from that company is suspicious before any other check is run.

We are honest about the limits of this layer. AI document verification is not infallible. A sufficiently sophisticated forger can produce documents that pass automated authenticity checks. This is why the document layer never operates alone; every claim with documentary support also has either peer attestation or government-ID cross-match supporting it, and significant disagreement between layers triggers manual review.

Layer 3: Government-ID cross-matching (India)

For India-based candidates, which represents a substantial portion of the Cloudhire network, we operate a third verification layer specific to the Indian regulatory environment.

Through verification partners with direct integration into government identity infrastructure, we cross-match each candidate’s Aadhaar and PAN against the identity they have presented to Cloudhire. The check is bidirectional. The Aadhaar must match the name, date of birth, and biometric data the candidate has registered with us. The PAN must match the candidate’s tax-filing identity. And the Aadhaar and PAN must match each other in the underlying records.

This three-way check produces an identity confirmation at a level that the US verification ecosystem does not have a clean equivalent for. An Indian candidate who passes the Aadhaar- PAN – presented-ID cross-match cannot plausibly be operating under a fabricated identity. The infrastructure does not allow it.

For candidates in other jurisdictions, the equivalent check uses the strongest government-issued ID system available in that jurisdiction, with the same principle: identity is confirmed against the highest-trust source the legal environment provides, not against documents the candidate produced themselves.

What Gets Verified, in Practice

Every Cloud-ID surfaces a verification status against each claim on the record:

Identity – government-ID cross-matched, biometrically persistent across all assessment sessions
Each prior role – peer-attested from verified corporate domains, document-supported, dates, and title confirmed
Education – institution-confirmed, where the institution responds, document-supported with AI authenticity check, otherwise
Certifications – registry-confirmed with the issuing body, expiration dates tracked
Right-to-work and compliance – jurisdiction-appropriate documentation, current status

When you search for candidates on Cloudhire, each profile shows you the verification status of every claim that was verified, by what method, and when. Where verification was incomplete or could not be obtained, that is also surfaced. We do not present incomplete verification as complete verification. The hiring manager sees the actual epistemic state of each fact, not a green checkmark that papers over uncertainty.

What This Is Not

This process is not a background check in the legal sense. We do not run criminal history checks, credit checks, or other regulated background screening; those are operated by licensed CRA vendors under jurisdiction-specific compliance frameworks (FCRA in the US, equivalents elsewhere), and clients who require them run them as a separate step using their own vendors. Cloudhire’s verification process confirms the truthfulness of what the candidate has told us about who they are and what they have done. It does not replace the legal background screening some roles require.

It is also not absolute. No verification process is. A candidate determined to defraud the system, with sufficient resources and patience, can compromise individual layers. The point of operating three independent layers is that compromising all three simultaneously fake peer attestations from spoofed corporate domains, AI-undetectable forged documents, and a falsified government identity that passes registry cross-match is a level of operational sophistication that places the candidate well outside the normal staffing fraud profile and into a category that no commercial verification process is designed to defeat.

For the standard fraud cases, inflated titles, fabricated tenure, embellished accomplishments, identity misrepresentation, and credential exaggeration, the three-layer process catches them before they reach a client dashboard.

How Verification Connects to the Rest of the System

Verified data is the precondition for everything else Cloudhire does. The Adaptive Skill Index calibrates against the candidate’s verified seniority and stacks a candidate claiming senior backend experience receives a senior backend assessment, and the calibration only works if the claimed background is real. The soft-skills evaluation uses a verified operational context to assess fit. Distributed team experience, regulated-environment exposure, and client-facing history are all assessment inputs, and they are inputs only when verified. The Integrity Engine assumes the person being assessed is the person whose record is being built, and that assumption is enforced through identity verification at this layer.

The verified record is the candidate’s Cloud-ID. Every layer above it depends on the verification beneath.

Search Candidates Whose Claims Have Already Been Confirmed

You stop verifying employment yourself. You stop wondering whether the credentials are current. You stop running the same identity check that three different vendors will charge you for. You filter, you read the verified profile, and you interview the candidates whose claims have already cleared the process.

Search for candidates on Cloudhire →