Stop Identity Farming in Hiring Assessments: An Ops Playbook

Treat identity farming as a repeatable pattern: one real person creates a "clean" verification once, then reuses their face and voice to shepherd many accounts through assessments. The tell is correlation, not a single failed check. You are looking for clusters: repeated device fingerprints, shared networks, unusually consistent completion timing, and session concurrency that is hard for a genuine candidate to reproduce. Start with passive signals because they are low friction and fast. Step-up verification should be a response to risk, not a default tax on every candidate.

Implement this as a Risk-Tiered Verification ladder. You want high throughput for low-risk candidates and deterministic containment for clustered risk. Step 1: Establish an "Assessment Identity" checkpoint. Bind the assessment session to a verified candidate identity with a short re-auth at assessment start. Do not rely on the earlier application verification alone because farming often happens after the initial gate. Step 2: Score passive signals continuously. Update risk during the assessment, not only before it. Verification is a state that can change when the device, network, or behavior changes. Step 3: Trigger step-up checks on clusters. When you detect correlation (same device across multiple applicants, or concurrency), require stronger proof at the moment of value: before score submission or before results are released to the hiring team. Step 4: Add a controlled retake policy. Identity farming thrives when retakes are unlimited and unstructured. Allow retakes only through Support-mediated workflows tied to Evidence Packs and reason codes. Step 5: Define fallbacks for real candidates. If ID scan fails or a camera is unavailable, route to an accessibility-safe alternative (manual doc review, scheduled live verification) with SLA targets so Support does not become the bottleneck. Step 6: Close the loop with hiring decisions. If a candidate is flagged, do not let managers "work around" the system. Provide an explicit waiver mechanism that logs who approved, why, and what evidence was reviewed.

Below is a deployable policy skeleton Support can point to when candidates appeal. It encodes step-up triggers, evidence requirements, and fallbacks, and it avoids storing toxic data by referencing Zero-Retention Biometrics outputs and hashed identifiers. Treat this like configuration, not a PDF. If it is not idempotent and versioned, you will not be able to explain past decisions during disputes.

These are the three patterns that reliably create both more fraud and more Support tickets.

Your goal is consistent outcomes under pressure. Candidates will argue, managers will escalate, and Legal will ask what you knew and when. Make the Evidence Pack the unit of work. Every flagged candidate should have a single bundle: timestamps, signal summaries, verification outcomes, and the exact policy version applied. Support should never hunt across tools mid-call. Operate with an SLA-bound queue: fast initial response, clear next steps, and deterministic dispositions (clear, step-up required, supervised retake, decline). Keep communications factual and avoid accusations. You are enforcing process integrity, not litigating intent.