How to Test Xverum for EU ATS Profile Enrichment

Before you wire a third-party employment-data provider such as Xverum into a production ATS enrichment flow, you have one question to answer: is this the right source at all? A vendor can publish impressive coverage and freshness claims, but for EU candidate data those claims are hypotheses until your own records prove them. This guide is the structured pilot that tests them, so provider choice is a measured decision rather than a leap of faith.

The reason freshness has to be measured, not assumed, is that employment data decays continuously and at different rates across the EU. Eurostat found that the probability of an employed individual changing jobs between two quarters in 2025 ranged from 5 percent in Denmark and the Netherlands to 1 percent in Bulgaria, Czechia, Greece, Italy, Poland, and Romania, per its labour market flow statistics (data extracted June 2026). The wider picture is the same: the US Bureau of Labor Statistics reported median job tenure of just 3.9 years in January 2024 in its Employee Tenure in 2024 release. A "current employer" field is a snapshot that starts going stale immediately.

Stale data is not just a quality problem, it is a compliance one. GDPR Article 5(1)(d), the accuracy principle, requires personal data to be "accurate and, where necessary, kept up to date", and that "every reasonable step must be taken" to erase or rectify inaccurate data without delay. You can read it in Regulation (EU) 2016/679. Adopting a provider whose current-employer field is routinely wrong means shipping an accuracy failure into production. The four steps below turn that risk into a test you can pass or fail.

Start by getting a non-production evaluation key and an environment that is walled off from your live data. The single rule for this step is that test enrichment must never write to a real candidate profile. Scope the key, point it at a throwaway datastore, and confirm there is no code path from the pilot into production records. A pilot that can mutate live profiles is not a test, it is an uncontrolled change.

Then handle the lawful basis, because enriching real EU candidate records for a pilot is still processing of personal data. GDPR Article 6(1) makes processing lawful only if at least one of six bases applies, and for enrichment the realistic ones are consent under Article 6(1)(a) or legitimate interests under Article 6(1)(f). Decide which basis covers your seed records before you send a single call, and keep pilot data isolated and short-lived so the test does not quietly become a second, undocumented processing purpose.

A pilot is only as good as what you feed it. Seed a small set of EU candidate records for which you already hold trustworthy, current employment data, because that ground truth is what you will score the provider against later. Without it you can only check whether a field is populated, not whether it is right.

Spread the seed set across several EU markets and several roles. This is not busywork: as the Eurostat figures above show, quarterly job-change rates range from 1 percent to 5 percent depending on the country, so a provider that looks fresh in a high-churn market like the Netherlands may lag badly in a low-churn one, or the other way round. A seed set drawn from a single country tells you nothing about the markets you will actually operate in. Keep the set small enough to inspect every record by hand, but broad enough that one country or one job family cannot flatter or sink the result on its own.

Now send the enrichment calls for every seeded record and capture the raw responses verbatim, not a summarised view. You are auditing three things beyond "did it return something":

• Field coverage. For each record, note which fields actually come back populated. A provider that returns a current employer for 40 percent of your seed set is a different proposition from one that returns it for 90 percent, and coverage often varies by country, so record it per market.
• Source attribution. Check whether each returned fact carries a source or provenance signal. This is not a nice-to-have. Because enrichment data does not come from the candidate, GDPR Article 14 applies, and it requires you to tell the candidate "from which source the personal data originate", within a reasonable period and at the latest within one month. A provider that cannot tell you where a fact came from cannot support that notice.
• Freshness signals. Look for a last-refreshed or as-of timestamp on each record, and capture it. Freshness is the field you most need to score in step 4, and you cannot score what the response does not expose.

Two technical details make the audit clean. Normalise every date the provider returns to a single format before you compare anything, using the timestamp profile in IETF RFC 3339, so a mismatch reflects real disagreement rather than day and month order. And when you batch the calls across the seed set, expect rate limiting: a compliant API returns HTTP 429, defined in IETF RFC 6585, so honour any Retry-After and back off. How the provider behaves under load is itself part of what you are evaluating.

The final step converts the captured responses into a decision. For each record, diff the returned current employer, job title, and employment dates against your ground truth, and record a per-field match rate plus a freshness result. Freshness matters as much as the match: a title that was correct two years ago is still an accuracy failure today under Article 5(1)(d).

Set the pass and fail thresholds before you look at the output. This is the discipline that keeps a pilot honest, because it is easy to move the goalposts once you have seen a number you like. Make the thresholds proportionate to how the field is used. The UK Information Commissioner's Office, in its guidance on the accuracy principle, advises that "the more important it is that the personal data is accurate, the greater the effort you should put into ensuring its accuracy". So hold current employer and current title, the fields that steer hiring decisions, to a stricter bar than incidental fields. Treat missing source attribution as an automatic fail, however good the match rate looks, because it breaks the Article 14 duty from step 3.

Finally, log the whole pilot: the seed set, the raw responses, the thresholds, and the scores. GDPR Article 5(2), the accountability principle, requires you to be able to demonstrate compliance, and a documented, reproducible test is exactly that. It also means the next provider you evaluate can run against the same seed set for a like-for-like comparison.

Passing the pilot answers "is this provider worth adopting", but it is not the end of the work. Choosing a source and validating individual writes are two different jobs. Once a provider clears your acceptance criteria, you still validate every enrichment before it lands on a live profile. The EU ATS profile enrichment data validation guide covers the per-record layers that come next, and the ATS integration API guide covers wiring the chosen provider into your ATS reliably at scale.

If you would rather validate against a source that already returns structured, source-attributed employment data, that is the layer RecruitAI Suite provides as APIs you call from your own product. The Data Enrichment API returns current, structured employment data you can run through the same scoring, and the Resume Parser API turns raw resumes into clean fields you can diff the same way. ATS and CRM teams can see how this slots in on the ATS vendors page, and the full set is on the product list. When you want to run this pilot against your own records, you can book a demo for API access and a walkthrough.