Most HR tech teams do not begin their fraud-prevention evaluation with a vendor shortlist. They start with a question their existing stack cannot answer: why are fake candidates getting through, and what would actually stop them?
That starting point matters because it shapes what you need to evaluate. A fraud prevention buyer at a bank is choosing between known vendors with established feature sets.
A product manager at an ATS platform is asking a different question: whether to build, what signals matter for a hiring use case and how a fraud API fits into a workflow that was never designed around fraud.
This guide is for that second buyer. It covers the five questions to ask before you look at any vendor, how to structure a build vs. buy decision, what actually to test in a pilot and the compliance considerations specific to HR tech platforms processing candidate data.
Key Takeaways
Why HR Tech Platforms Need a Different Evaluation Framework
Fraud prevention tooling was built for financial services, and the default evaluation criteria reflect that. Chargeback rates, transaction decline rates and the impact on conversion from false positives do not translate to a hiring context where there are no transactions and the cost of a false positive is a rejected candidate rather than a lost sale.
The attack surface is also different. Financial services fraud typically targets payments or accounts. ATS fraud targets the identity layer of a hiring workflow, aiming to get a fake person through screening rather than stealing money directly. That distinction changes which signals matter and which do not.
HR tech platforms also face different compliance requirements. They process candidate personal data on behalf of employer clients, which means any fraud signal vendor they use is processing that data as a sub-processor.
The GDPR obligations that follow from that structure are specific and cannot be handled with a generic data processing agreement written for a fintech use case.
The evaluation framework that works for a bank will not work here. Building the right one starts with five questions.
The Five Questions to Ask Before Evaluating Any Vendor
1. What attack surfaces do you actually need to cover?
The answer determines your signal requirements. If candidates apply directly through your platform, you have access to device and IP data at the point of submission, which gives you access to the full signal stack. If applications arrive via email or third-party feeds, you will work only via email and phone. Both are viable, but they require different configurations and produce different detection rates.
2. Do you have the data collection infrastructure to use device and IP signals?
Device fingerprinting and IP intelligence require a JavaScript SDK integrated into your application portal to collect session data at submission. If that infrastructure does not exist, a vendor offering device signals is offering something you cannot yet use. The question is not whether device signals are valuable (they are), but whether your current architecture supports them and, if not, what the implementation path looks like.
3. What does your integration path actually look like?
A single REST API call is the standard integration model for fraud enrichment. The question is where in your workflow you call it, what data you pass and what you do with the response. Do you want a risk score that feeds into your own decisioning model, or do you want the vendor’s rules engine to make the call? The answer affects how you evaluate configurability, not just signal coverage.
4. How will you handle GDPR as a data processor?
ATS platforms are typically data processors acting on behalf of employer clients. A fraud signal vendor processing candidate data on your behalf is a sub-processor. Your data processing agreement (DPA) with that vendor needs to explicitly reflect that relationship, including data retention limits, processing purpose restrictions and the vendor’s stance on data ownership.
5. What does good detection look like at your volume and price point?
Detection accuracy at 15,000 applications per month looks different from detection at one million. Volume affects the pricing tier, which affects per-check cost, which in turn determines whether the economics of fraud prevention work for your platform. Know your current volume, your projected volume and the price point at which fraud prevention becomes unviable before you enter a pricing conversation.
Build vs. Buy: Where In-House Efforts Hit the Wall
The build vs. buy question comes up early in most HR tech fraud evaluations, and for good reason. Platforms already have engineering teams, they understand their own data and building in-house feels like the path to the most customized solution.
In-house builds tend to work well up to a point. Email validation, basic IP checks and simple rule logic can be implemented with engineering effort and off-the-shelf APIs. The wall most teams hit is the fresh credentials problem: fraudsters targeting ATS platforms create new email addresses and phone numbers for each campaign, specifically because in-house models, and most point solutions, have never seen those credentials and have nothing to flag them on.
Solving that problem requires a signal layer that has processed enough data across enough platforms to detect the absence of history, not just the presence of known fraud signals. That requires the network effect of a vendor processing billions of data points annually across thousands of customers, which means seeing the same fresh email address submitted across multiple platforms before your in-house model has any record of it.
The build vs. buy decision usually resolves once teams understand this distinction. Building the rules engine and decisioning layer in-house is sensible. Buying the enrichment signals that feed that engine is where a specialist vendor adds value that you cannot replicate internally.
What Signals Actually Matter for Candidate Fraud Detection
Not every signal in a fraud API is equally useful for hiring workflows. Evaluating a vendor on feature count rather than signal relevance is one of the most common mistakes HR tech teams make.
The signals that matter most for candidate fraud, in order of detection weight:
- Email age and digital footprint depth — email anchors detection, because it is present on every application, regardless of how candidates apply
- Phone CNAM match — carrier lookup tells you a number is active; CNAM tells you whether the name registered to it matches the application
- IP and device context — session-level signals that no individual credential check surfaces
- LinkedIn profile corroboration — meaningful when other signals are inconclusive, but cannot serve as a primary signal because not all candidates have a profile
How a vendor handles each of these, and how deep their data goes, is what separates effective detection from surface-level checking.
Email deliverability is not a fraud signal. An address that exists and can receive messages tells you nothing about whether it was created yesterday. The question is what history is attached to it: social media registrations, data breach appearances and account age across platforms.
Phone
Carrier lookup tells you whether a number is active. CNAM data tells you whether the name registered to that number matches the name on the application, and that second check is the one that catches fake candidate operations at scale. Fraud operations reusing phone numbers across campaigns cannot control the registered name on every number they use, which creates a consistent detection opportunity.
IP and Device
A residential proxy IP address combined with a device that has submitted applications under multiple identities in the same week is a pattern that no individual credential check would surface. These signals require a JavaScript SDK integrated into your application portal, which is why question two in the evaluation framework above matters before you assess a vendor’s device capabilities.
When an email address is submitted, enrichment checks whether it links to a LinkedIn profile and whether that profile’s connection count, activity history and career data are consistent with what the CV claims. It does not catch every fake candidate, but it catches the ones who have invested in breadth of digital presence without professional depth.
For a structured comparison of vendors offering these signal types, see Best Fraud Detection Software and Tools in 2026.
How to Evaluate a Fraud API for ATS Integration: Checklist
Use this checklist when running a pilot or vendor evaluation. Each item maps to a question that a smoke test or proof of concept should answer before you commit.
Signal depth:
- Does the email check return account age, social media presence and data breach history, or just deliverability?
- Does the phone check return CNAM data and VoIP detection, or just carrier lookup?
- Can the IP check distinguish between residential, data center and residential proxy connections?
- Is LinkedIn enrichment available as part of the email signal response?
Integration:
- Is the full signal stack available in a single API call, or do different signals require separate calls?
- Does the vendor provide a JavaScript SDK for device and session data collection?
- Can you pass a client or employer identifier to configure per-account rules without exposing one employer’s data to another?
Decisioning:
- Does the vendor’s rules engine allow you to build and backtest custom rules against your own historical data?
- Does the machine learning layer suggest rules based on your labeled outcomes, or does it apply a generic model?
- Can you run the vendor’s score alongside your own decisioning model rather than replacing it?
Commercial:
- Is pricing per API call, and does it include all signals, or are add-ons like CNAM or LinkedIn enrichment charged separately?
- What volume tier are you in at your current and projected check volume, and what is the per-check cost at each tier?
- Is there a trial or pilot period at reduced commitment before a full contract?
Compliance:
- Does the vendor’s DPA explicitly position them as a data processor rather than a data controller?
- What are the data retention limits for candidate personal data processed through the API?
- Does the vendor have existing DPAs written for GDPR-regulated use cases, or will you need to negotiate one from scratch?
Data and Compliance Considerations
Compliance is not an afterthought for HR tech platforms. It is often the decision that unlocks or blocks the commercial conversation.
Candidate personal data carries specific obligations under GDPR. An ATS platform processing that data on behalf of employer clients is a data processor. A fraud signal vendor processing it on the platform’s behalf is a sub-processor. That chain of responsibility needs to be documented, with the sub-processor’s DPA explicitly reflecting it.
The specific sticking point in most vendor evaluations is the consortium data question. Fraud signal vendors improve detection accuracy by leveraging shared network data. If an email address has been labeled as fraudulent across multiple customers, that signal feeds back into the enrichment response for others.
That mechanism is valuable for detection but raises questions about how candidate data is used beyond the immediate processing purpose.
A vendor that anonymizes consortium signals — returning a risk indicator without identifying which customer labeled it or why — resolves most of these concerns. The question to ask explicitly is: does processing candidate data through your API mean that the data contributes to your consortium model, and, if so, how is it anonymized before it does?
The answer to that question, not the presence of a DPA, is what determines whether the integration is compliant with your obligations to employer clients.
See how SEON works for HR tech
Speak with an expert
Frequently Asked Questions
The attack surface, integration context and data obligations are all different. Financial services fraud targets payments and accounts. ATS fraud targets the identity layer of a hiring workflow. The signals that matter, the integration architecture and the GDPR position of a platform processing candidate data on behalf of employers do not map onto a financial services evaluation framework.
Building the rules engine and decisioning layer in-house is sensible because you understand your risk tolerance better than any vendor. The wall most in-house builds hit is the enrichment signal layer, specifically the need to detect fresh credentials that have never been seen before. That requires a vendor processing at scale across thousands of customers, which is not replicable with engineering effort alone.
Email age and digital footprint depth, combined with phone CNAM matching, catch the majority of fake candidate patterns. Adding IP intelligence and device fingerprinting improves detection significantly when candidates apply through a portal. LinkedIn enrichment adds a cross-validation layer specific to professional hiring. You do not need all four to start, but the fewer signals you run, the more sophisticated the fake candidates that get through will be.
Fraud API pricing is usage-based, meaning the per-check cost decreases as volume increases. At low volumes, per-check costs can make fraud prevention economically unviable for every application. The typical approach is to start at a lower volume commitment and graduate into higher tiers as adoption grows. The key question is whether the vendor’s pricing model allows for that graduation without requiring a full contract renegotiation at each tier.
