How We Verify: the dual-checkpoint compliance architecture
Most recruitment compliance software checks a candidate once and trusts the result until someone remembers to renew it. That gap — between when a check happened and when a shift actually starts — is where placements go wrong. Here's exactly how we close it.
The problem with "checked once"
A right to work check, a DBS certificate, a professional registration — every one of these has a shelf life. Some expire on a fixed date. Others lapse quietly: a visa condition changes, a registration is suspended, a DBS certificate's update service flags something new. Industry-standard practice is to check at onboarding and set a renewal reminder. That's better than nothing. It is not the same as knowing a candidate is compliant on the actual day they turn up to work.
Every AI recruitment platform we researched frames "compliance" as a governance question about its own systems — SOC 2 certifications, GDPR statements, responsible-AI charters. Those matter, but they describe how the platform handles data, not whether the person it's placing is actually cleared to be there today. We built the dual-checkpoint model specifically to close that second, more consequential gap.
Checkpoint one: screening
Every candidate sourced from a client's own consented CRM is verified individually — right to work, DBS or equivalent background check, professional registration where relevant, training currency, and references. Each item is checked separately against its own authoritative source; nothing is inferred from a single composite "pass" score. This is the checkpoint every serious platform in the category performs. We treat it as the floor, not the finish line.
Checkpoint two: placement day
Immediately before a placement is confirmed as starting, every checkpoint-one item is re-verified live against its current authoritative source. If a registration lapsed last week, if a right-to-work condition changed, if a DBS update-service flag appeared since screening — the placement does not proceed until it's resolved. This is a structural hard stop in the pipeline, not a warning a human can override under time pressure. See where this sits in the full eight-stage pipeline →
Why this is a GDPR-conscious design, not just a compliance one
UK GDPR's treatment of automated decision-making turns on whether human involvement is genuine — someone with real authority to change the outcome, reviewing the actual case, not rubber-stamping a system's output after the fact. Our placement-day checkpoint is designed around that standard directly: a flagged discrepancy routes to a named human with the authority to resolve or halt it, every time, regardless of deadline pressure. We'd rather lose a placement to a compliance gap than paper over one.
What this means for your agency
Fewer compliance write-offs. No placement goes live on a technicality nobody caught. And when a client, auditor, or framework body asks "how do you know this candidate was actually compliant on day one" — the honest answer is a re-verified, timestamped record, not a screening file from six weeks earlier.
Want the full technical detail — which sources we check against, how the placement-day re-verification integrates with your existing CRM, and where the human review point sits in your specific workflow?
Request access under NDA