Hiring fraud used to be the employer’s problem. That assumption no longer holds. As applicant tracking system (ATS) platforms process millions of candidate profiles on behalf of thousands of employers, fraudsters have shifted focus, and the platforms that run these workflows have become the primary attack surface.
Applicant tracking system fraud occurs when malicious actors exploit applicant tracking system platforms to submit fake, synthetic or stolen candidate identities, bypass hiring workflows, harvest employer data or position fraudulent hires within target organizations.
This article is for product, engineering, fraud and trust & safety leaders at ATS and HR tech companies. It covers the fraud patterns your platform faces, why standard verification fails to detect them and what an effective detection layer looks like in practice.
Key Takeaways
Why ATS Platforms Have Become a Fraud Target
Fraudsters follow volume. ATS platforms now process tens of millions of applications annually, many via automated ingestion pipelines that minimize friction at the point of submission. That scale is precisely what makes them attractive to bad actors.
The shift to remote hiring removed the natural friction of geography. A candidate no longer needs to appear in person to advance through a hiring process, which means a single remote hiring fraud operation can submit thousands of convincing applications across dozens of platforms simultaneously.
For ATS vendors, this creates a specific liability. Enterprise clients are increasingly requiring fraud-prevention controls as a procurement condition, and platforms that cannot demonstrate candidate integrity checks are losing deals to those that can.
The Five Fraud Patterns Hitting ATS Platforms Right Now
Synthetic identity applications
A fraudster assembles a candidate profile using a combination of real and fabricated data: a legitimate name, a freshly created email address and a plausible employment history. The identity passes basic checks because parts of it are real. The goal is to reach an interview, harvest recruiter contact details or gain access to employer systems via onboarding.
Credential farming via fake profiles
Fraudsters register on ATS platforms not to get hired but to collect recruiter outreach. Every inbound message from a recruiter is a warm contact, useful for phishing, social engineering or selling access to hiring pipelines. Platforms with low registration friction are particularly exposed because the cost of creating a fake profile is near zero.
Payroll diversion via account takeover post-hire
This pattern begins at the application stage but pays out months later. A fraudulent hire, or a legitimate employee whose credentials have been compromised, gains access to payroll or human resources information systems (HRIS) and redirects direct deposit to a mule account. Application fraud and financial fraud are treated as separate incidents, but they are part of the same attack chain.
Fake employer accounts are harvesting candidate PII
Some ATS platforms allow employers to self-register, which opens a second attack surface. Fraudsters create fake employer accounts to access candidate profiles, contact details and CVs, data that feeds identity fraud operations elsewhere. The platform becomes an unwilling data broker for organized fraud.
Deepfake and proxy interview fraud
Increasingly, fraudsters pass video interviews using AI-generated deepfakes or by having a more qualified person interview while the actual hire is someone different. The identity that gets onboarded is not the identity that was screened. This pattern is accelerating in tech hiring, where remote-first workflows are the default.
Why Standard Identity Checks Are Not Enough
Document verification catches fraudsters who steal or fabricate physical documents. It does not catch fraudsters who create synthetic digital identities, which is the dominant pattern in ATS fraud today.
The core problem is the creation of newly generated personally identifiable information (PII). Fraudsters targeting ATS platforms do not reuse known fraudulent identities. Instead, they create fresh email addresses and phone numbers for each application campaign because this is cheap, fast and easy to execute at scale. Consortium-based models, which flag PII already associated with fraud, miss these entirely because the credentials have never been seen before.
Standard email validation confirms whether an address is deliverable. Still, it cannot determine whether that address was created yesterday, has no associated accounts anywhere on the internet and belongs to a device that has already submitted 40 applications this week. That gap is where ATS fraud operates.
What Effective ATS Fraud Detection Actually Looks Like
Effective detection for ATS platforms combines four signal types in a single API call: email enrichment, phone enrichment, IP intelligence and device fingerprinting. Together, they produce a risk score that reflects the full context of the candidate session, rather than whether individual data points look valid in isolation.
Email intelligence goes beyond deliverability. It checks whether the email address has an associated social media presence, how many platforms it appears on, when the oldest account was created and whether it has been involved in a data breach. A legitimate professional email will typically show years of activity across multiple platforms, while a freshly created fraud email will show none of that.
Phone enrichment checks carrier data and whether the number is registered to a voice over internet protocol (VoIP) service. It also checks whether the name associated with the number matches the name on the application — a mismatch here is a strong signal, particularly for high-volume fraud operations that reuse phone numbers across campaigns.
IP and device intelligence matter most when candidates apply through an ATS portal. A candidate applying from a data center IP, using a virtual private network (VPN) to mask a device located in a different country from the claimed address, presents a very different risk profile from someone applying from a residential connection. Device fingerprinting also detects when the same physical device submits multiple applications under different identities, a pattern that would otherwise be invisible.
LinkedIn enrichment provides a cross-validation layer specific to professional hiring. If an email address on an application is linked to a LinkedIn profile, the enrichment returns the profile URL, connection count, career history and education. A CV claiming ten years of software engineering experience but linked to a LinkedIn account created last month will surface that discrepancy immediately.
Together, these signals produce a risk score that evolves with the fraud pattern. Machine learning (ML) models trained on labeled fraud outcomes suggest rules based on what has actually been fraudulent in your candidate pool, not a generic model built for a different industry.
How ATS Vendors Are Embedding Fraud Prevention as a Product Feature
The commercial model for ATS fraud prevention has largely settled on a usage-based application programming interface (API) approach. Platforms pay per check, with volume discounts at scale, and receive a risk score, with contributing signals broken down by attribute, via a single API call.
This architecture matters for the product decision. One integration point means one vendor relationship and one pricing model to manage. The platform controls what score threshold triggers a flag, what data is surfaced to recruiters and whether decisioning is automated or advisory.
The commercial rationale is increasingly clear from enterprise procurement. Applicant fraud detection is becoming a table stake that enterprise clients expect bundled into the core product. Platforms that charge extra for it are at a disadvantage; those that embed it as a standard feature are winning deals on compliance grounds alone.
The integration path follows three stages. The API is first integrated at application submission, enriching each record in real time. Rules are then configured to reflect the platform’s specific risk tolerance. Finally, the labeling loop is established, so that flagged application outcomes feed back into the model over time.
Building a Fraud Prevention Layer Into Your ATS: Key Considerations
Data Processor vs Controller Positioning
Any fraud prevention integration involving candidate personal data must be structured correctly under GDPR. The ATS platform is typically a data processor acting on behalf of employer clients, and the fraud signal vendor processes data on behalf of the platform. Both relationships need to be reflected in your DPA. The key question for vendor evaluation is whether the fraud vendor takes a processor stance, meaning they do not claim ownership of the data and do not use it beyond the agreed processing purpose.
Integration Architecture
The JavaScript SDK approach collects device and session data from the application portal in real time, passing it alongside email, phone and IP in a single API call on submission. Platforms without a candidate-facing portal can still email and phone enrichment on ingestion. The signal depth is lower, but it catches the majority of synthetic identity patterns.
Volume and Pricing
Fraud API pricing is usage-based, which means per-check costs at low volumes can be significant relative to the value of each application. At scale, platforms processing hundreds of thousands of applications per month, volume discounts bring that cost down substantially. Evaluate pricing at your actual expected volume, not a notional minimum tier.
Multi-Tenancy and White Labeling
If your platform wants to surface fraud scores to employer clients inside your own UI, discuss white-label options with your vendor upfront. Most fraud API providers support passing a client identifier, allowing rules and thresholds to be configured per employer account without exposing one employer’s data to another.
Managed Risk Services
Platforms without an internal fraud team can access managed fraud analyst services from some vendors. This option provides dedicated analysts who monitor traffic, tune rules and surface emerging patterns, effectively outsourcing the ongoing fraud operations function until an in-house capability is built.
Frequently Asked Questions
Applicant tracking system fraud refers to the use of fake, synthetic or stolen candidate identities to exploit ATS platforms, whether to pass hiring screens, harvest employer data, farm recruiter contacts or gain fraudulent employment. The ATS platform is the attack surface, not just the employer behind it.
Synthetic identities combine real and fabricated data. Fraudsters typically use a legitimate name with a freshly created email address and a plausible employment history. Because parts of the identity are real, basic validation checks pass. The tell is the email address: newly created, with no digital footprint and no associated accounts on any platform.
Standard validation confirms an email is deliverable. It does not check how old the address is, whether it has associated accounts or whether the device submitting the application has been used for other applications. Fraud rings create fresh email addresses for each campaign specifically because standard validation will pass them.
A full-signal API call combines email enrichment, phone enrichment, IP intelligence and device fingerprinting. Together, these yield a risk score that reflects the full context of the candidate, not just whether individual data points appear valid. LinkedIn enrichment adds a cross-validation layer specific to professional hiring contexts.
Yes. Email and phone enrichment can be run on application data at ingestion, even when applications arrive via email or third-party feeds. Device and session signals require a candidate-facing portal or SDK integration, but email and phone signals alone catch the majority of synthetic identity patterns.
Background checks verify historical facts about a candidate: criminal records, employment history and qualifications. Fraud prevention operates in real time at the point of application, before any investment in screening has been made. It detects whether the identity submitting the application is likely to be real, not whether the claimed history of that identity is accurate. The two functions are complementary, not substitutes.
Evaluating a fraud prevention layer for your ATS platform? Explore how SEON works for HR tech
