Indian background verification filed against the candidate

On a US desk the screening conversation is usually about criminal history. On an Indian IT desk it is overwhelmingly about employment: did this person work where they say they worked, for the period they say, in the role they say, and did they leave the way they say they left. Education verification and address verification sit alongside it, and identity documents underpin all of them.

That difference changes what the integration has to carry. A result is not a single pass or fail. It is a set of components, each with its own status, its own source and its own turnaround, and an offer decision often turns on one component coming back as a discrepancy rather than on the whole file failing.

Employment verification in India is commonly run against provident-fund service history, because the contribution record assembled under a candidate's universal account number shows which employers contributed and for which months. Reading that history is the standard way overlapping employment is detected in Indian IT hiring, where a candidate drawing from two employers in the same period is the pattern the client is asking about when they say moonlighting.

The verification itself is performed by the provider you contract with, using the consent the candidate gave them. Surhires does not query any government service, does not hold a universal account number as a verification input and does not adjudicate a discrepancy. What it would do is record that a component was ordered, what came back and what you did about it.

Verification results in India frequently return discrepancies that are administrative rather than dishonest: an employer recorded a different designation than the offer letter used, a contribution gap reflects a period on a third-party payroll, a name spelling differs across two documents. Treating every discrepancy as a disqualification loses good candidates and makes the whole exercise a rubber stamp.

So the record has to distinguish between what the check returned and what you decided. Disposition codes are a fixed list rather than free text, so an audit trail reconstructs the decision, and the coded reason sits alongside the filed result rather than replacing it. Whether a discrepancy disqualifies a candidate is your call, and your client's, not the CRM's.

It also means the client can be told something specific. A submittal withdrawn because a contribution gap could not be explained is a different conversation from one withdrawn because two employers overlapped by nine months. Clients running Indian technology programmes generally want to know which of the two they are looking at, and the record should be able to say.

Order the check in AuthBridge's own portal against your own account, with the components the client has asked for. When results return, file them against the candidate record in Surhires: which components were run, the status of each, the completion date, the ordering user, and the decision you took including the coded disposition.

File the candidate consent you or the provider collected alongside it. The product supports notice and consent records against candidate profiles and portability export under the DPDP Act, and you remain the entity responsible for the candidate data you hold. Document capture and expiry reminders already work; the verification itself is a workflow you run.

A verification file contains identity documents, employment records and sometimes financial identifiers, and it should not be readable by every recruiter in the office. Field-level permissions restrict who can open it, every access is logged with actor and timestamp, and retention windows mean the documents are removed on a schedule rather than kept because nobody chose one.

Where your policy says a raw identifier should never be stored in the CRM, file the provider's verification reference and the outcome instead of the underlying document. That keeps the audit trail intact without making the candidate database the most sensitive system in your business.