Confirm a candidate is who the resume says they are

A background verification asks whether the history is true. An identity check asks whether the person presenting the history is the person it belongs to. They are ordered at different points, they return in different timeframes, and confusing them produces a file that looks complete and is not.

Document verification confirms that an identity document is genuine and that its details match what the candidate provided. A video check adds liveness and a face match, which is the part that addresses proxy attendance at an interview or at onboarding. Both are performed by the provider; Surhires would carry the order and the outcome.

When an agency submits a candidate who turns out to be a different person at onboarding, the immediate cost is the placement. The lasting cost is the client relationship and, on a managed programme, the supplier position. It is the kind of failure that ends a preferred-supplier arrangement rather than generating a credit note.

That is why identity belongs on the submittal path rather than in onboarding. Recording that a verification was ordered and what it returned, against the candidate and against the requisition, means the answer to did we verify this person exists in the same place as the rest of the placement file.

It is also cheaper at that point. An identity problem found before a submittal costs an hour. The same problem found in the client's onboarding costs the placement, the recruiter's standing with that hiring manager and, on a managed programme, an explanation to a supplier manager who now has a note on file about your firm.

The design intention is that Surhires stores a verification outcome and a provider reference rather than becoming a repository of identity documents and biometric material. That is a smaller, safer footprint for a system that hundreds of recruiters log into every day, and it is the right default even where a customer's policy would permit more.

Where documents must be held, field-level permissions restrict who can open them, every access is logged with actor and timestamp, and configurable retention windows remove them on a schedule. Demographic data used for equal-opportunity reporting is stored separately from the hiring record and is not visible to recruiters at all; identity material follows the same instinct.

Order the check in IDfy's own portal against your own account. When it returns, file the outcome on the candidate record in Surhires: which components were run, the result of each, the date, the ordering user, and the provider's reference. Attach the certificate where your policy allows; where it does not, the reference and the outcome are enough to reconstruct what happened.

Record the consent the candidate gave as well. The product supports notice and consent records against candidate profiles and portability export, and you remain the entity responsible for the data you hold. The verification itself is a workflow you run, not a certification we hold.

Identity verification requires the candidate's agreement, and that agreement is usually captured in the provider's flow rather than in the CRM. Six months later, when a client or an auditor asks on what basis a check was run, the flow is gone and the record is a PDF in somebody's downloads folder.

Filing the consent basis, when it was captured and through which channel, against the candidate record is a fifteen-second habit that answers the question permanently. It is the same field the product already uses for candidate data consent, and it is the reason that field is on the record rather than in a settings page.

It matters commercially as well as legally. An agency that can produce consent records on request is an agency that survives a client vendor review. One that cannot spends a fortnight assembling something that should have been a two-minute report.