.svg){kind=small}
.svg){kind=small}
Remote hiring fraud succeeds most often not because verification tools fail, but because interview and identity checks run on separate tracks and never confirm the same human across both. One person performs in the live technical round; a different person holds a real government ID to the camera for a vendor that never watched the interview. The chain of custody breaks between stages, and most teams only discover it after production access is already granted.
If you are a head of engineering, a security-minded founder, or a technical hiring manager, public filings and industry warnings are not background noise. The FBI and DOJ have documented proxy setups and synthetic identities in remote IT hiring at scale. Gartner predicts that by 2028, one in four candidate profiles will be fake. These are the same headwinds you feel every quarter, and they point to one structural gap: remote hiring scaled faster than most teams wired who interviewed to who passed ID.
This article explains how interview and verification get decoupled and what it takes to close that gap. It also walks through a real case from Remotely's network where early signals were caught, escalated, and handled against written guidelines, so the pattern is concrete, not theoretical. For the full picture, the other two articles in this series cover the full-funnel verification layer and assessment-stage AI and deepfake controls separately.
You can run a clean process and still have one structural gap you never designed around: the tool that checked the ID was never shown the face from the interview. Everything clears. The gap was always there.
How interview and ID checks describe two different people
Hiring teams rarely skip identity checks. What usually fails is integration, not the existence of a check. Know Your Customer (KYC) or an equivalent ID and liveness step often runs where money and compliance already live: a payments tool, HRIS add-on, bank stack, or generic onboarding app, not your interview system. Those flows are built to clear a name for payroll or a vendor; they are not built to prove the person in the interview and the person in the ID flow are the same human. The credential can clear, the biometric match can be a real person, and that can still be someone who was not in the interview, including whoever walked your team through your own system design with credible depth.
That is the structural gap: KYC in that shape proves document and liveness in the identity step your payroll or onboarding stack runs, not that the interviewee and the person who onboards are one continuous identity. What is missing is chain of custody: Person A carries the interview; Person B passes ID with real artifacts. The failure is often not a forged document; it is that no step required both to register as the same individual in one system of record.
Engineering and technical roles are the stress test in this story because, once that chain is wrong, the risk is temporal, not “weak resume”: the interval from a cleared check to a plausible hand on production-adjacent work can be very short, so a bad bind has little time to stay harmless. The same split can appear in other functions; the examples here lean technical to keep that clock visible. For how the U.S. Department of Justice has described nationwide coordinated work in this space, the FAQ below answers that in plain terms, and a public entry point is the Department’s release on associated charges and seizures.
First party: patterns from the Remotely network
The pattern we observed was consistent across attempts. Before the first live round, the profile signals were already misaligned: place of origin and residence in tension, resume and LinkedIn out of sync on dates and scope, profile text heavy on keywords with no depth underneath, and in some cases a headshot that read as synthetic. Strong English was present in written materials, but when our plurilingual team checked for the regional language tied to the claimed background, whether Spanish at a local register, Portuguese, or a regional variant, the fluency was not there or did not hold under natural conversation. No single signal was conclusive on its own. The pattern was in how they stacked, and it took human reviewers across languages, not a single automated flag, to see it clearly.
In a separate set of cases, the split ran in the opposite direction. The ID verification step completed without friction: government document real, liveness check passed, IP aligned with the claimed location. It was only when the same individual joined the live technical round that the inconsistency surfaced. The person on camera could not match the depth the resume implied, switched communication style mid-conversation, and in one case used a name in their verbal introduction that did not match the verified document. The verification had been done on the right person. The interview exposed that someone else had been doing the preparation.
The structural cost of missing this is not a single bad hire. It is granting production access, repository rights, and customer data exposure to someone your interview panel never met. We know what that means for the companies and partners who trust us with their hiring: a breach in that handoff is not an inconvenience, it is a liability that lands on their infrastructure, their clients, and their reputation. Each step performed as designed. The gap was never in any one step. That is exactly why we built a process that covers it.
One individual appeared in customer-facing materials under the name "Alejandro." The person screened in the live round was not the person who attempted ID verification. That single case illustrates what both routes have in common: the scheme only works if interview and identity are never confirmed against the same human at the same time.
None of the attempts on the Remotely network succeeded. Both routes, a strong performer hiding behind a borrowed identity and a verified identity masking an unprepared impostor, are patterns our team has seen, documented, and closed. What stops them is system checks that bind interview to identity for the same individual, backed by a highly experienced human vetting team that knows what misalignment looks like before it reaches an offer. We update both continuously. As fraud methods evolve, so does our process, and we do not leave a gap in that chain of custody for network engineers or for the candidates you meet through us.
From signal to policy: your next moves
Everything described above points to one rule you can put in front of any executive or hiring partner: the human who earns trust in the interview is the same person who passes identity confirmation before high-trust access is granted. If that is not the case, you are not closing the gap, you are choosing who owns the risk when it opens.
That rule does not require a new tool category or a platform overhaul. It requires a decision about where in your process the two confirmations meet, who is responsible for checking that they do, and what happens when they do not align. Most hiring chains already have the individual steps. What they are missing is the binding between them, the moment where someone with authority looks at both and confirms they point to the same person.
The reason that binding is rare is not technical. The interview team and the verification team are usually separate functions, operating on separate timelines, reporting into separate owners. No one is incentivised to slow an offer down by asking whether the person who impressed in the technical round is the same person whose ID just cleared. That question feels like friction. It is actually the only question that closes the route both fraud patterns depend on.
One principle, applied consistently across every stage of the hiring chain, by people who know what misalignment looks like and have the authority to stop the process when they see it.
Why cost-plus and bound identity go together
The interview-versus-ID gap does not persist by accident. Market structure affects whether anyone in the hiring chain is actually incentivised to close it.
Hidden markup models and speed-first platforms are built to fill seats and hit SLAs. They reward throughput, not verification. When the margin is hidden and the metric is time-to-offer, proving that the person who interviewed is the person who onboards is friction, not a feature. Nobody owns that question because nobody is paid to ask it.
Remotely is structured differently. Compensation is visible under a cost-plus model, so there is no margin to protect by moving fast and skipping steps. Live human screening comes first. Government ID and live biometrics are then bound to the same individual admitted through that screen, not run as a separate parallel track. Background checks run by default at offer stage. References follow a structured flow designed to tie to verifiable professional profiles where policy allows. Each step confirms the same person, not a green check on a different person at a different time.
That is not a claim that this is the only way to run a hiring process. It is a description of one stack that matches the rule this piece has been building toward: the person who earns trust in the interview is the same person who clears identity before access is granted, and the economics do not create an incentive to skip that confirmation.
If that matches how you think about hiring risk, map the role or read how we work with hiring teams.
Frequently Asked Questions
What is the “interview versus identity verification” gap in remote hiring fraud?
It is a process split: one human performs interviews and builds trust, while a different human completes KYC or ID checks that still pass, because that second person holds a real ID and passes biometric match. If your stack does not tie those moments, you can get a green ID and still onboard the wrong worker.
How does the U.S. Department of Justice describe large-scale remote IT worker identity fraud?
In public filings and press materials, the Department has described coordinated schemes in which people use false or stolen identities to hold remote U.S. IT work, with compensation moved through U.S. payment systems and with proxy- or cutout-style roles in the flow; some major matters tie the proceeds, in the government’s characterization, to North Korean revenue generation or related goals. The facts and charges are case-specific. For exact language, named defendants, and what is charged versus decided, use primary sources: start at justice.gov and follow the complaints and dockets, or a representative public announcement summarizing coordinated actions in that space.
What pattern did Remotely see in attempted network infiltration?
Multiple individuals tried. Early on, the file often would not add up: place of origin versus where they said they lived, résumé and LinkedIn that disagreed on experience, language that did not pass what we would expect for their claimed region of residence, profile text heavy with high-traffic keywords, and in some cases a synthetic or AI-generated headshot.
At our identity step, a different person than we had interviewed then presented a real government ID, an IP consistent with that ID, and a selfie that passed liveness. Each time, interview and ID still described two different people, so the path did not clear. None were placed or added to the network; a customer-escalated case, including a figure that appeared in client materials as “Alejandro,” led us to tighten the binding between live screening and ID verification.
Why is software engineering hiring a higher-stakes target for this fraud?
Engineering and platform roles are usually given technical access in days, not months: source code, build and deploy paths, production-adjacent services, and often customer, user, or regulated data, sometimes plus finance-adjacent or payroll-adjacent tools.
In the split-interview-versus-ID pattern, the point of failure is that the wrong person can still inherit that access with a “clean” check from a tool that never saw the interview. That combination of early reach and a wide blast radius is why the stakes sit above many non-technical functions, and why U.S. enforcement has treated remote IT identity abuse as a serious operational problem rather than a hiring inconvenience.
Were the individuals involved (including “Alejandro”) ever part of the Remotely network?
No. The attempts described in this article did not clear Remotely's verification process. None of those individuals were placed through the platform or entered the active network. The case, which included a figure that appeared in client-facing materials under the name "Alejandro," was escalated internally, reviewed against our screening guidelines, and used to tighten the binding between live interview records and ID verification as standard procedure going forward.
How does Remotely ensure the person interviewed is the person who completes identity verification?
We run live, human screening first, then government-issued ID and live biometrics, bound to the same person we already admitted to the process, so a “clean” ID result cannot clear for someone who did not go through that interview record.
Default background checks at offer sit alongside ID, and references follow a structured path. The series articles on full-funnel verification and on technical interviews, take-homes, and session integrity are where teams mirror larger layer stacks; on our side, the design is a single chain of custody from live screening to identity proof before someone enters the network or a supported hire.
