Automated Candidate Compliance Checks: A UK Guide

Most agencies treat compliance checking as a paperwork task. It is not. Right to Work checks carry civil penalties of up to £60,000 per illegal worker. DBS obligations vary by role type and sector in ways that are easy to get wrong. FCA regulatory reference requirements under SYSC 22 apply to specific individuals regardless of whether your compliance tool has a field for them. The legal exposure is specific, the documentation requirements are specific, and the thresholds are specific.

Automation is a delivery mechanism for compliance - it is not a substitute for understanding what compliance actually requires. Before you integrate a verification tool into your ATS or build a workflow that fires off checks automatically, you need to know which checks are legally required, what the audit trail must contain, where human sign-off is irreplaceable, and where the data protection obligations sit. That is what this guide covers.

It is written for recruitment agencies operating in regulated sectors - healthcare, education, financial services - in-house HR teams at scale-ups bringing compliance tooling in-house, and anyone building or reviewing an automated candidate compliance checks workflow against an ATS.

Which Checks Are Legally Required and Which Are Best Practice

The distinction matters more than most compliance documentation makes clear. Right to Work checks are mandatory under the Immigration Act 1971. As of 2024, the civil penalty for employing an illegal worker without a statutory excuse is up to £60,000 per worker. The check must be conducted before employment starts - not during onboarding, not after the first day. DBS checks are mandatory under the Rehabilitation of Offenders Act 1974 (Exceptions) Order 1975 for specific role types, but the level of check - standard, enhanced, or enhanced with barred list - varies by sector and role. You cannot substitute an enhanced DBS for a standard one because it feels more thorough. The level is prescribed, not discretionary.

FCA regulatory references are required under SYSC 22 of the FCA Handbook for senior managers and certified persons under the Senior Managers and Certification Regime (SMCR). If you are placing into financial services roles that fall under SMCR, these references are not optional, and the six-week response window has to be built into your placement timeline.

What is not legally required but frequently treated as if it is: credit checks for non-financial roles, social media screening, and reference periods extended beyond what the role actually warrants. Running a credit check on a healthcare support worker without a clear lawful basis is a UK GDPR exposure, not a compliance tick. The fact that your compliance tool makes it easy to add the credit check to the workflow does not mean the check is justified. Processing it without a documented lawful basis creates a liability rather than removing one.

Worker classification is a compliance variable, not just a payroll one. A PAYE contractor placed in a school triggers different obligations than a self-employed consultant working in the same school. The employment relationship determines which checks apply and who is responsible for conducting them.

The sector-specific stacking is where agencies most often under-configure their workflows. Healthcare placements via NHS frameworks require Right to Work plus DBS plus occupational health clearance - all three are mandatory, and none substitutes for another. Education adds the Teachers' Barred List check. Financial services adds FCA fit and proper assessments. These stacks are not interchangeable. An agency moving into a new sector cannot simply copy its existing compliance workflow and expect it to be legally sufficient.

What Automated Candidate Compliance Checks Actually Handle End-to-End

Right to Work digital verification via Identity Document Validation Technology (IDVT) certified providers - Yoti, TrustID, Sterling Identity, and others - can satisfy the statutory excuse for British and Irish passport holders and those with a UKVI share code. That is the genuine scope of the automation. Anything outside that requires a human: manual document review for overseas candidates, expired biometric residence permits, or physical leave to enter stamps in a non-biometric passport. The tool handles a defined subset of cases well. Outside that subset, it either fails silently or flags for manual review that may or may not actually happen.

DBS applications can be initiated and tracked automatically. The disclosure certificate is issued to the applicant, not the employer. What the employer or umbrella body receives is the certificate number and result status. The decision about whether a particular disclosure is compatible with a particular role is a human judgement call - it cannot be delegated to a system, and any workflow that treats a "clear" result as an automatic green light is missing a step. Enhanced disclosures with barred list checks require a considered decision, especially when the disclosure contains information short of a barring.

FCA regulatory reference requests under SYSC 22 can be triggered automatically, but the receiving firm has six weeks to respond, and the content of that response - conduct history, disciplinary findings, risk assessments - requires a compliance officer to assess. No tool automates that assessment, and you should be sceptical of any vendor claiming otherwise.

Specific failure modes to know about before you build:

• False negatives on document verification: OCR-based tools misread date fields on older UK passports, particularly where laminate wear affects the machine-readable zone. A passport that is valid gets flagged as expired. The candidate chases the recruiter. The recruiter assumes the tool is right. The placement is delayed unnecessarily.

• Address mismatches: candidates who have moved recently often have a discrepancy between the address on their ID document and the address held on file. This triggers a false flag. Without a defined resolution workflow, it either stalls the check or gets dismissed without proper documentation.

• Employment gaps: automated reference tools send requests to employers listed by the candidate and return no data for gaps. The tool marks the reference as unable to verify. The obligation to investigate the gap sits with the recruiter. If the workflow does not explicitly prompt that investigation, it does not happen.

Right to Work Automation Post-Brexit: What the 2022 IDVT Framework Actually Allows

From 6 April 2022, employers can use IDVT-certified providers to conduct digital Right to Work checks on British and Irish citizens with valid passports, including Irish passport cards. This replaced the temporary COVID-19 adjusted checks and created a permanent digital route carrying statutory excuse protection. It was a meaningful change and it did simplify the process for a significant portion of candidates.

What IDVT does not cover is the gap most compliance content ignores entirely. Biometric residence permit (BRP) holders and eVisa holders must use the Home Office Online Right to Work Checking Service via a share code. That is a separate system, not an extension of the IDVT route. A certified IDVT provider scanning a BRP is not conducting a valid Right to Work check, and the statutory excuse does not apply. Several automated compliance platforms present BRP verification as part of the same document verification workflow as passport checks. That is wrong. If you have a vendor doing this, raise it with them directly and get written confirmation of how they handle BRP and eVisa cases - then verify the answer against the Home Office guidance.

The statutory excuse protects an employer who followed the correct process and employed a worker whose document later turned out to be fraudulent. If the employer used a DIATF-certified provider correctly and the document passed verification, the excuse applies even if the document was fraudulent. If the employer used a non-certified provider, or applied IDVT to a document type not in scope for the digital route, the excuse does not apply - even if the process looked identical from the outside.

A compliant audit trail for Home Office inspection should contain: a timestamped record of the check, the provider used and their IDVT certification status at the time of the check, the document type verified, the result, and the date of verification. Retain this for the duration of employment plus two years. The record needs to be retrievable from a system you control - not locked in a third-party compliance tool that you may not have access to if you change provider or if the tool is deprecated.

IDVT-certified providers as of writing include Yoti, TrustID, Sterling Identity, Experian Identity, and Credas (formerly HooYu). These are certified under the UK Digital Identity and Attributes Trust Framework (DIATF). Verify current certification status via the government's published register before committing to a provider - certification can lapse and the register is the definitive source.

UK GDPR Obligations That Automated Compliance Systems Must Satisfy

The lawful basis for processing compliance check data is not the same for all candidates. For candidates who are hired, the lawful basis is typically contractual necessity under Article 6(1)(b) and, where the check is a legal requirement (Right to Work, DBS), compliance with a legal obligation under Article 6(1)(c). For candidates who are screened but not hired, contractual necessity does not apply. The lawful basis shifts, and if you are relying on legitimate interest, you need a documented Legitimate Interests Assessment. Most agencies have not done one.

Retention periods are where automated systems most reliably create GDPR exposure by default. Right to Work records should be retained for the duration of employment plus two years, per Home Office guidance. DBS certificate data has a more specific constraint: the Disclosure and Barring Service Code of Practice states that the content of a DBS certificate should not be retained for more than six months. The certificate number and the recruitment decision can be retained - the certificate content should not be held beyond six months unless you have explicit documented justification. Most ATS integrations and compliance tools retain this data indefinitely unless you configure them otherwise. That is not a vendor problem you can ignore - it is your GDPR exposure.

Subject Access Requests are a practical operational gap worth flagging explicitly. Candidates have the right to request access to their compliance records. If your compliance tool (Sterling, Zinc, Veremark, or similar) holds check results that are not surfaced in your main data register, those records may not be included in your SAR response. The tool sits outside the process, the data sits in it, and the SAR process does not reach it. This is a common gap and it is the kind of thing that surfaces during an ICO investigation rather than during a routine audit.

Some checks involve special category data under Article 9 UK GDPR - DBS checks and occupational health clearances both touch this. Processing special category data requires a lawful basis under Article 6 and a condition under Article 9, typically Schedule 1, Part 1 of the Data Protection Act 2018 for employment purposes. Automated systems must be configured to handle this correctly. Most vendors will not proactively tell you whether their system meets this requirement - you need to ask, get it in writing, and check it against your DPA.

Integrating Compliance Checks into a Recruitment ATS Without Creating Data Silos

The typical architecture: a compliance tool - Sterling, Zinc, Veremark, or similar - sits alongside the ATS, whether that is Bullhorn, Vincere, or JobAdder. The integration, where it exists, is usually webhook-based. The compliance tool fires a status update to the ATS when a check completes. The candidate record in the ATS shows a compliance status field. That is the intended design and it works well when it works.

Where it breaks in practice is webhook failures. If the webhook from the compliance tool fails to deliver - because of a timeout, an ATS API rate limit, or a misconfigured endpoint - the check status in the ATS does not update. The compliance tool shows "complete". The ATS shows "pending". Nobody notices until a consultant tries to place the candidate. There is usually no alerting on failed webhooks unless you have explicitly built it. Building dead-letter handling and retry logic is not complicated, but it requires someone to have thought about it when the integration was set up. In most implementations, nobody has.

Data duplication is the other risk. Some integrations copy the full check result - document images, certificate content - into the ATS record. That creates a duplicate data store for sensitive compliance data, which compounds the GDPR retention problem. The correct approach is to store a reference in the ATS - check ID, status, date, outcome - with the full record accessible only in the compliance tool under appropriate access controls. The ATS is the system of reference, not the system of record for compliance data.

If you are building this in Bullhorn, the compliance data typically lives on the Candidate or Placement record via custom fields. Triggering the check can be done via a Bullhorn workflow automation or via n8n if the native integration between Bullhorn and your compliance tool is insufficient or unreliable. The webhook back into Bullhorn requires a working API key with entity permissions scoped correctly - write permissions on the Candidate record, at minimum. Worth testing the webhook under load before go-live, not after a failed placement.

Managing Recheck Cycles for Ongoing Worker Compliance

Pre-hire checks are where most tools focus. For agencies placing workers into healthcare, education, or financial services, ongoing compliance is where the operational complexity actually lives. A Right to Work verification is valid until the worker's visa expiry date - at that point, re-verification is a legal requirement. Miss it and you lose the statutory excuse for the period after expiry. A DBS check has no statutory expiry date, but NHS frameworks and many local authority frameworks require rechecks every three years as a condition of the framework. FCA annual fitness and propriety assessments are required for certified persons under SMCR - they are annual, not one-off.

The practical approach is to automate the expiry tracking, not the recheck itself. Store visa expiry dates, DBS check dates, and FCA assessment dates against the worker record. Build automated alerts at 90 days out, 30 days out, and 7 days out, firing to the compliance team and the account manager. What happens when the alert fires is a human decision. The automation handles the tracking and the prompting - that is a reasonable scope for it.

When a placed worker's compliance lapses mid-contract, the worker must be stood down. The agency has an obligation to notify the end client. Depending on the contract terms, liability for any breach during the lapsed period may sit with the agency, the client, or both. Standard agency terms typically place the ongoing compliance monitoring obligation on the agency for their own workers, but end clients have a parallel duty of care. Many contracts are ambiguous on where liability sits when a lapse occurs during an active placement. Worth reviewing the standard terms with a lawyer before it becomes relevant rather than after.

Handling Edge Cases: Overseas Candidates, Name Changes, and Employment Gaps

Overseas candidates: IDVT coverage applies to British and Irish passport holders. For candidates from outside the UK and Ireland, the Right to Work check must go through the Home Office Online Checking Service if they have a UKVI-issued status, or via manual document review for those with physical leave to enter or remain stamps in a non-biometric passport. Automated tools have weak or no coverage for this. The correct approach is to define a clear manual review workflow for overseas candidates - assign responsibility to a named role, not "the compliance team" generically, and document each step in the same audit trail format as the automated checks. The absence of a documented manual process is typically where liability accumulates.

Name changes: automated document matching fails when a candidate's current legal name differs from the name on an older document. Common triggers are post-marriage name changes and post-transition name changes. The correct process is to request the change document - marriage certificate, deed poll, gender recognition certificate - and verify the chain from the original document through to the current name. Automated tools will either flag a mismatch or, worse, pass the check incorrectly if the name similarity threshold is configured too loosely. Manual review must be explicitly triggered for any name discrepancy, not left to the tool's judgement call.

Employment gaps: automated reference tools send requests to employers listed by the candidate and return no data for gaps. The tool typically marks the reference as "unable to verify" and moves on. The compliance obligation to investigate the gap sits with the recruiter. Configure the workflow so that any employment gap over 28 days triggers a manual follow-up task with a defined resolution step - either a written explanation from the candidate, or the gap confirmed and documented - before the check is marked complete. If the workflow does not enforce this, it will not happen consistently.

If you are building or reviewing automated candidate compliance checks for a recruitment agency, or integrating compliance tooling into Bullhorn or another ATS, the starting point is a clear picture of what your current workflow actually does versus what you think it does. The Revenue Audit at stacklogic.co.uk/services covers that diagnostic - mapping the real process, identifying where the legal obligations are being met and where they are not, and scoping what needs to be built or fixed before any automation is layered on top.