The home page card is deliberately compact. This article is the full version. The core argument: in background verification, "closed" is not a timestamp. It is a claim that the verification record behind the case is complete enough to withstand scrutiny. When that claim is false, the risk does not disappear. It waits.
What case closure actually means
Every verification case ends with a closure event. That event has a timestamp, and on a vendor dashboard it generates a metric: the case moved from "open" to "closed" at this moment on this date. But the timestamp and the substance behind it are two entirely different things.
Dashboard timestamp closure
On a dashboard driven model, closure is a state change triggered by one of two conditions: either the work is done, or the SLA window has expired. Both conditions produce the same status label. Both generate the same TAT metric. The dashboard does not distinguish between a case that closed because every check was verified and a case that closed because seven days elapsed. The metric treats them identically.
This is not a bug in the software. It is a design choice that optimises for throughput reporting. The vendor's operations team needs a way to move cases off the active queue, and the SLA ceiling provides a clean mechanism. From an operational standpoint, it works. From an audit standpoint, it is a liability.
Evidence based closure
In an operator led model, closure is not a state change. It is a conclusion. The case closes when one of two conditions is met: every contracted check has been verified against a primary or secondary source, or every reasonable verification path has been attempted, documented, and the client has been notified of what remains unverified and why. The first is evidence backed closure. The second is documented reasonable exhaustion. Both are defensible. Neither is governed by a timer.
Three closure types
Not all closures are equal. In practice, verification cases close through one of three mechanisms. Click each card to see the detail, what it looks like in a report, and how an auditor evaluates it.
Evidence backed closure
Documented reasonable exhaustion
Artificial closure (the one to avoid)
The "unable to verify" problem
"Unable to verify" (UTV) is the most overused status in background verification. It appears in reports from every vendor type, but the rate at which it appears, and the documentation that accompanies it, varies dramatically depending on how the vendor handles case closure.
The gap is significant. A high volume platform vendor may ship reports with UTV status on nearly half of all cases. An operator led model keeps UTV below 10%, and when it does appear, the accompanying documentation is sufficient to explain why. The question for any client is straightforward: what percentage of your workforce was hired on the basis of an incomplete verification record?
Two closure paths
The diagram below traces the same verification scenario through two models. A candidate's education check is pending because the university registrar has not responded. Watch the steps animate as you scroll to see how each model handles the same institutional delay.
The dashboard path produced a metric compliant closure in 7 days. The operator path produced an evidence backed closure in 8 days. One day of difference. But the dashboard path left the education check unverified, and twelve months later, if that candidate's credentials come into question, the report cannot answer the most basic question: did this person actually hold the degree they claimed?
What documented reasonable exhaustion looks like
There are genuine situations where full verification is not possible. An institution may have closed permanently. Records for a particular period may have been destroyed in a natural disaster. A former employer may have been dissolved with no successor entity. In these cases, closing without full verification is the correct decision, provided the closure is properly documented.
Documented reasonable exhaustion requires five elements:
- Contact log with timestamps. Every attempt to reach the institution must be recorded: date, method (email, phone, physical visit), contact person or department, and the outcome of each attempt.
- Escalation trail. The log must show that the verification team did not simply repeat the same contact. Alternative paths must have been tried: different departments, alternative contact numbers, local field agents, professional networks.
- Reason for exhaustion. A specific, documented reason why verification could not be completed. "No response" alone is insufficient. The reason must explain what was tried and why no further path exists.
- Client notification. The client must be informed before closure that a component will remain unverified. This notification must include the reason, what was attempted, and the client's acknowledgment or instruction to proceed.
- Clear labelling in the report. The unverified component must be distinctly marked, with the exhaustion documentation accessible in the case file. An auditor reviewing the report should be able to trace the full effort without contacting the vendor.
Three consequences of premature closure
Premature closure, closing a case before the evidence supports it, does not generate immediate visible harm. The cost is deferred. It surfaces when the verification record is tested by an external event. Select each tab to see how premature closure plays out in practice.
Consequence 1: the audit that exposes the gap
A financial services regulator conducts a routine review of your firm's hiring controls. They sample 30 employee files and request the underlying BGV reports. Of the 30, eleven reports contain at least one component marked "unable to verify" with no supporting documentation of what was attempted. The regulator counts these as unverified hires. Your firm's verified hire rate drops to 63%, well below the 95% threshold your compliance framework requires. The finding generates a remediation action, a timeline for re-verification, and a note in the supervisory record. Your vendor's SLA metrics were excellent throughout.
Consequence 2: the incident that tests the record
An employee is terminated for falsifying client records. Your legal team pulls the original BGV report to assess whether the hiring decision was defensible. The report shows employment verification for two prior roles. One is marked "verified". The other is marked "unable to verify: institutional non response within SLA". The employee's falsified role was at the unverified employer. The verification programme failed at the one point where it mattered most. Your legal team cannot demonstrate that reasonable steps were taken because the vendor's case file contains only an automated email and no follow up trail. The litigation exposure now includes a negligent hiring argument.
Consequence 3: the re-verification bill
You switch BGV vendors after two years. The new vendor conducts a portfolio review of prior reports as part of onboarding. They flag every case with an undocumented UTV status for re-verification. The result: 34% of your prior workforce needs to be re-verified. At an average cost of 40% above original per case pricing (because re-verification of tenured employees is harder than initial checks), the bill is substantial. Worse, some employees have since left, making the exercise partly futile. The original vendor's fast, cheap TAT metric now carries a deferred cost that exceeds what a thorough initial verification would have cost.
Operator led closure in practice
The operator model does not guarantee that every check will be verified. No model can, because institutional responsiveness is outside any vendor's control. What the operator model guarantees is that no case closes without either evidence or a documented, defensible reason for its absence. The difference is in the closure protocol, not in the outcome promise.
Dashboard closure model
- Closure is a workflow event triggered by SLA expiry or task completion
- "Unable to verify" is a valid, routine closure status
- No escalation protocol beyond one or two automated follow ups
- Client notified after closure, if at all
- Case file contains the final status but not the investigative trail
- Metric: percentage of cases closed within SLA window
Operator closure model
- Closure is an evidentiary conclusion reached by a named specialist
- "Unable to verify" requires a documented exhaustion protocol
- Multi-step escalation chain: email, phone, alternative contacts, field agent
- Client notified before closure on any unverified component
- Case file contains the full contact log, escalation trail, and closure rationale
- Metric: percentage of cases closed with evidence or documented exhaustion
In practical terms, this means an operator led programme tracks two closure metrics. The evidence backed closure rate measures the percentage of cases where every contracted check was verified against a source. The documented exhaustion rate measures the percentage where at least one check could not be completed but the exhaustion protocol was followed. Together, these two numbers represent the programme's defensible closure rate, typically above 95% for a well run operator programme, compared to 58 to 72% for a dashboard model when measured by the same standard.
Five questions to ask about case closure
These questions surface how your vendor handles the moment of closure. They do not require a report audit. They require honest answers.
- What percentage of your cases close with at least one component in "unable to verify" status? Break this down by check type, corridor, and whether the UTV was accompanied by a documented exhaustion trail.
- When a case cannot be fully verified within your standard timeline, what happens? Walk me through the escalation chain, step by step, from first contact to final closure decision.
- Under what conditions does your system automatically close a case? Is there a hard SLA ceiling that forces closure regardless of evidence state?
- Do you notify the client before closing a case with an unverified component, or after? Can you show me an example of that notification, including the information provided?
- For a randomly selected case with a UTV component, can you produce the full contact log showing every attempt made, every escalation step, and the documented reason verification was not achievable?
Frequently asked questions
"Unable to verify" is a status label that can mean anything from "we tried everything and the institution genuinely cannot respond" to "our SLA timer ran out and we stopped trying". Documented exhaustion is a specific protocol: every contact attempt is logged with dates and outcomes, alternative paths are tried and recorded, a reason for non completion is documented, and the client is notified before closure. The status label may be the same, but the evidentiary substance behind it is entirely different. Under audit, only documented exhaustion is defensible.
Yes. There are genuine situations where full verification is not possible: an institution has permanently closed, records were destroyed, or a former employer has been dissolved with no successor. In these cases, closing without full verification is the correct decision, provided the closure follows a documented exhaustion protocol. The five elements are: a timestamped contact log, an escalation trail showing alternative paths attempted, a specific reason for non completion, client notification before closure, and clear labelling in the report with accessible documentation.
Artificial closure creates latent audit risk. When a regulator or internal auditor samples employee files and finds BGV reports with undocumented UTV statuses, those employees are counted as unverified hires. If your programme has a 35% UTV rate (the industry average for SLA driven vendors), roughly one in three sampled files will fail the audit test. The finding typically generates a remediation requirement: re-verify the affected population within a specified timeline, at your cost, with reporting obligations to the regulator.
The rate depends on the corridor and check mix. For Indian candidates with a standard full pack (employment, education, criminal, address, identity), an operator led vendor with a documented exhaustion protocol should maintain a UTV rate below 10%, and those UTV cases should each have a full contact log and exhaustion trail. A rate above 25% on any single check type, particularly education or employment, is a strong signal that the vendor is using SLA driven auto closure rather than pursuing evidence.
Marginally, on a per case basis. The difference is typically 1 to 3 days for cases that involve institutional delays. But operator led programmes offset this through two mechanisms. First, they avoid the rework cycle: cases that auto close and later need to be re-opened or re-verified consume more total time than cases that were worked thoroughly the first time. Second, they use interim reporting to give clients actionable information within 48 hours, so the hiring process is not blocked while a single check is being pursued.
An interim report is a partial deliverable issued before the case is fully closed. It shows the current status of each component: which checks are verified, which are in progress, and what the next step is for any pending item. Interim reports allow the client to make conditional hiring decisions without waiting for every check to complete, while ensuring that the final report is evidence backed. The case remains open until all components reach either "verified" or "documented exhaustion" status. This separates the hiring timeline from the closure timeline.
Every case closes through one of two paths: evidence backed closure (all contracted checks verified against a primary or secondary source) or documented reasonable exhaustion (structured protocol followed, client notified, full contact log preserved). We do not use SLA driven auto closure. There is no hard timer that forces a case to close regardless of evidence state. Our closure metrics track the percentage of cases in each category, and we report both numbers to clients monthly. For cases requiring extended follow up, we issue interim reports within 48 hours so that hiring is not delayed.
Yes. Request a sample of 50 recent reports and focus on cases with any UTV component. For each one, ask the vendor to produce the full case file: contact log, escalation trail, reason for non completion, and evidence of client notification. If the vendor can produce this documentation readily, their closure protocol is likely sound. If they cannot, or if the case files contain only a status label with no supporting trail, that is a clear signal of artificial closure. The five questions listed in this article can also surface closure practices without requiring a full report audit.
References & further reading
- How We Operate: the operating methodology section on the home page, where this deep dive series originates.
- Speed vs artificial closure (article 01): the three mechanics of artificial closure and their operational cost.
- Verification depth (article 02): why database lookups and direct institutional verification are not interchangeable.
- Audit defensibility (article 03): what an audit ready verification record actually contains.
- Compliance brief: audit trail requirements and the 15 questions TPRM teams ask.
- TPRM self assessment: pre-scored vendor evaluation framework including closure protocol questions.
Next Step
Map case closure by corridor.
Run the coverage diagnostic by corridor to see where closure typically breaks, or request a structured proposal.