What "speed" actually means on a dashboard vs under an audit
On a vendor dashboard, "speed" is one metric on a strip: average TAT, 7-day closure rate, or some variant. It is derived from the difference between two timestamps: case opened, case closed. It is agnostic to what happened in between and agnostic to why the case was marked closed.
Under an audit, whether a regulator enquiry, an internal audit of hiring controls, or a workforce-integrity investigation, speed is not a metric. The auditor asks a different question: how was this specific candidate verified, with what evidence, from which sources, and is the documentation sufficient to defend the decision that was made on the back of it?
The gap between the two matters. A vendor can report excellent dashboard speed while producing reports that fail the audit-defensibility test. And in our industry, that gap tends to surface 12-24 months after the engagement began, often in a scenario where the client has no good options.
Three mechanics of artificial closure
Artificial closure isn't a single behaviour. It's three distinct mechanics, each with its own tell. Click each card to reveal the detail and what to look for in your reports.
Metric-driven auto-closure
Scope reduction under pressure
Database-only substitution
The speed-depth tradeoff, visualised
All verification programmes face a curve. Push reported TAT down aggressively and one of three things has to give: depth per check, the set of checks performed, or honesty about which cases were actually verified. The curve below illustrates how reported speed relates to evidence quality across the industry, and where the inflection point sits.
Realistic TAT ranges: what honest verification actually takes
The chart below shows the operational reality per check type for Indian candidates, the corridor where we have the deepest data. These are honest ranges: the working time from complete documentation to evidence-backed closure, not the marketing TAT.
The numbers above add up honestly to a 5-8 day full-pack TAT for a tier-1-metro Indian candidate with PF-registered employers, and 8-14 days for a tier-2/3 candidate with affiliated-college degrees and rural address verification. Any vendor promising sub-4-day full-pack TAT on Indian candidates is, with high probability, relying on at least one of the three artificial-closure mechanics.
Two case-closure paths
The diagram below compares how a case closes on a dashboard-driven vendor versus how it closes in an operator-led programme. Same inputs. Different closure logic. Watch the steps animate as you scroll.
Notice what the two paths actually optimise for. The dashboard path optimises for the metric. The operator path optimises for the record the case leaves behind. The dashboard path is 3 days faster. The operator path is 100% verified instead of 66% verified. Twelve months later, when a regulator asks which method you chose, the answer matters.
What goes wrong 6-24 months later
Artificial closure doesn't produce immediate visible harm. It produces latent exposure, a growing backlog of under-verified candidates in your workforce, defensible only to the extent your vendor's reports can be stood up under scrutiny. The cost materialises when one of four scenarios unfolds.
Scenario 1: Workforce-integrity incident
A hired employee is implicated in internal fraud, data theft, or harassment. Your compliance team pulls the BGV report. The report shows "education: unable to verify: institutional non-response within SLA window". The candidate's education credentials were never actually confirmed. Your vendor's SLA was protected; your control posture was not.
Scenario 2: Regulated-industry audit
An industry regulator (financial services supervisor, insurance regulator, health authority) reviews your hiring controls. They sample 20 employee files and ask for the evidence chain behind each verification. "Unable to verify" responses are counted as unverified hires. Your regulator-facing position depends on the percentage.
Scenario 3: Data-protection investigation
A data-protection authority investigates a breach. As part of the investigation, they assess whether candidates whose data you processed through a sub-processor (your BGV vendor) had their data handled per contract. If the vendor's evidence chain is thin because cases were artificially closed, your position as controller weakens.
Scenario 4: Programme handover to a new vendor
You switch BGV vendors. The new vendor reviews the prior reports as part of onboarding and asks to re-verify any case with "unable to verify" status. Depending on the artificial-closure rate, you may be re-running the programme at 30-60% of the prior scope. The direct cost is the re-verification bill; the indirect cost is the commercial signal you gave procurement when you negotiated the original rate card on the back of the old vendor's "fast" TAT claim.
What operator-led speed actually means
"Operator-led" is sometimes dismissed as a slower alternative. In practice, operator-led programmes are often as fast or faster than dashboard-driven ones on end-to-end measured TAT, because the time wasted on failed auto-closures, re-opened cases, and rework is saved upfront by doing the verification properly the first time. What they don't do is manufacture speed through closure mechanics.
Dashboard model
- SLA clock starts when the case is opened
- One or two automated follow-ups, then auto-close
- "Unable to verify" is a valid closure status
- Speed is the primary performance metric
- Reports delivered within SLA regardless of evidence state
Operator model
- SLA clock starts when documentation is sufficient
- Structured follow-up with specialist escalation
- Cases close on evidence or documented reasonable exhaustion
- Defensibility is the primary performance metric; speed is the outcome
- Interim reports within 48 hours; final on evidence
The practical consequence is that operator-led programmes publish two numbers, not one: the sufficiency-to-interim TAT (how quickly the client has something actionable) and the sufficiency-to-final TAT (how quickly evidence-backed closure happens). Both numbers are honest. Neither is inflated by closure mechanics.
Seven questions to ask a BGV vendor about speed
These are the questions that surface the three mechanics of artificial closure without needing to audit a report sample. We'd be happy to be asked any of them.
- What percentage of your cases close with any component in "unable to verify" status? Broken down by check type and corridor.
- When does your SLA clock start: on case open, or on confirmation of complete documentation?
- For each check type in my programme, what specific institutional contacts or databases do you use? Name them.
- When a registrar or employer doesn't respond by your SLA, what happens next? Walk me through the follow-up chain.
- Do you offer interim reports? At what cadence, with what component-level detail?
- Under what conditions do you close a case without verifying every contracted check? How is that recorded?
- Can you show me the evidence chain for a randomly-selected anonymised case: source, method, actor, timestamp, response?
Frequently asked questions
Artificial closure is when a background verification case is marked as "closed" or "complete" before the evidence fully supports that status. It typically happens through one of three mechanics: auto-closing cases when an SLA deadline hits (regardless of whether institutional responses arrived), reducing the scope of checks mid-process to avoid delays, or substituting a database lookup for direct institutional verification. In each case, the dashboard reports a fast turnaround, but the underlying report may not withstand audit scrutiny.
Pull a sample of 50 recent reports and look for three patterns. First, count how many components carry an "unable to verify" or "institutional non-response" status; a high percentage signals metric-driven auto-closure. Second, check whether every contracted check type is present on every report; missing checks flagged as "scope-agreed" or "client-waived" indicate scope reduction. Third, look at the verification method: if reports list "national database" or "public records" without naming a specific registrar or bureau, that's likely database-only substitution.
For a tier-1 metro Indian candidate with PF-registered employers, an honest full-pack TAT (employment × 2 + education + criminal + identity + address) is 5-8 working days. For tier-2/3 candidates with affiliated-college degrees and rural address verification, expect 8-14 days. These are measured from complete documentation to evidence-backed closure, not from case open. Any vendor consistently promising sub-4-day full-pack TAT on Indian candidates is almost certainly relying on at least one artificial-closure mechanic.
Reported TAT is the number on the vendor dashboard: the time between "case opened" and "case closed". It's agnostic to what happened during that window or why the case was marked closed. Honest TAT is the time from when the candidate provides complete, sufficient documentation to when an evidence-backed report is delivered. The two typically diverge by 3-8 days. That divergence is exactly where artificial closure lives, and where audit risk accumulates.
Not in practice. Operator-led programmes are often equally fast or faster on end-to-end measured TAT. The reason: dashboard-driven vendors spend time on failed auto-closures, re-opened cases, client calls to negotiate scope reduction, and rework when an audit flags an incomplete report. Operator-led programmes invest that time upfront, doing the verification properly the first time. The difference is that operator-led speed is never manufactured through closure mechanics, so the reported number is honest.
The cost materialises in one of four ways. In a workforce-integrity incident, your compliance team discovers the BGV report is incomplete for the employee involved. In a regulated audit, unverified hires are counted against your compliance posture. In a data-protection investigation, a thin evidence chain weakens your position as data controller. And in a vendor handover, the new provider may ask you to re-verify 30-60% of prior cases at your cost. In every scenario, the vendor who sold you the fast TAT bears none of the consequence.
Seven questions cut through marketing: (1) What percentage of cases close with "unable to verify" on any component? (2) When does the SLA clock start: case open or documentation complete? (3) What specific institutional contacts do you use per check type? (4) What's the follow-up chain when a registrar doesn't respond? (5) Do you offer interim reports? (6) Under what conditions do you close without full verification? (7) Can you show the evidence chain for a random anonymised case? A vendor confident in their methodology will welcome every one of these. See our TPRM self-assessment for a scored version.
Yes, but with a critical difference. Our SLA clock starts when documentation sufficiency is confirmed, not when the case is opened. We publish two numbers: a sufficiency-to-interim TAT (how quickly you get something actionable, typically within 48 hours) and a sufficiency-to-final TAT (how quickly evidence-backed closure happens). Cases close on evidence or on documented reasonable exhaustion, never on a timer. Both numbers are honest, and neither is inflated by closure mechanics.
References & further reading
- How We Operate: the operating methodology section on the home page, where this deep dive series originates.
- The 6-step verification process: interactive walkthrough of how an operator-led case actually runs.
- India deep dive: realistic TAT expectations: per-check TAT ranges with sources.
- Compliance brief: audit trail, documentation, and the 15 questions TPRM teams actually ask.
- TPRM self-assessment: pre-scored vendor evaluation framework including the speed questions above.
Next Step
Map TAT by corridor before you commit.
Run the coverage diagnostic to see realistic turnaround windows by market, or request a structured proposal.