The home page comparison card on verification depth is deliberately brief. This page is the long version. The core argument: the word "verified" on a BGV report should mean that a human at the issuing institution (university registrar, HR department, licensing board) confirmed the credential. When all it means is that a database returned a record that matched the candidate's input, you have a lookup, not a verification. The distinction matters the moment anyone asks you to prove it.
What verification depth means
Verification depth describes how far down the evidence chain a vendor goes to confirm a candidate's credential. Think of it as a spectrum. At the shallow end, a system queries a database and checks whether the candidate's name and degree title appear. At the deep end, an analyst contacts the issuing institution directly, cross-references the response against a second independent source, and documents the evidence trail with timestamps, contact names, and method of confirmation.
The spectrum matters because each step deeper produces stronger evidence. A database match can be gamed (falsified records do appear in databases), can be incomplete (many databases cover only a fraction of institutions), and can be stale (records may not reflect revocations or corrections). Direct institutional contact is harder to forge, harder to circumvent, and produces a documented evidence chain that names a specific person at the institution who confirmed the credential.
Three categories define the spectrum:
- Database lookup: An automated query against a national or commercial database. Fast, cheap, and limited to whatever the database contains.
- Direct institutional contact: An analyst contacts the issuing institution (registrar, HR department, licensing authority) by phone, email, or official portal to confirm the credential directly.
- Field verification: A representative physically visits the institution or address to confirm the claim. Used when remote channels are unavailable or when the risk profile demands it.
Four levels of verification depth
We use a four-level framework to describe how deep a verification programme goes. Most dashboard vendors operate at Level 1 or Level 2. Operator-led programmes operate at Level 3 as the default, escalating to Level 4 when the corridor or risk profile demands it. Click each card to see the detail.
Database match only
Database + automated API confirmation
Direct institutional contact
Multi-source triangulation with field verification
Why database-only verification fails
The chart below shows the relative evidence quality produced by each verification method. Evidence quality here means: if this report is sampled by a regulator, an internal auditor, or a client's TPRM team, how well does the evidence support the "verified" status on the report?
The gap between 35% and 95% is not marginal. A database match satisfies roughly one third of the criteria a regulator or auditor would look for. It confirms that a record exists. It does not confirm who entered that record, whether it is current, whether it accurately reflects what the candidate claimed, or whether the institution stands behind it. Multi-source institutional verification satisfies nearly all audit criteria because it produces named sources, dated confirmations, method documentation, and cross-referenced evidence.
The source hierarchy in practice
The diagram below compares how a dashboard vendor handles an employment verification versus how an operator handles the same check. Same candidate, same employer, same claim. Watch the steps animate as you scroll.
The dashboard vendor's report says "verified." The operator's report also says "verified." But the evidence behind each is fundamentally different. The operator's report can explain a discrepancy, name the HR contact who confirmed the tenure, and show the document that resolved the gap. The dashboard vendor's report contains a database query result and nothing else. Under audit, one holds. The other does not.
Country-specific depth requirements
Verification depth is not one-size-fits-all. Each corridor has its own institutional landscape: different database coverage levels, different response norms, and different fraud patterns. The examples below illustrate why a single global "database-first" approach produces unreliable results in the corridors where most offshore hiring happens.
South Asia: India, Pakistan, Bangladesh
Education: India's NAD covers approximately 40% of universities as of early 2026. For the remaining 60%, including many state universities, affiliated colleges, and deemed universities, there is no centralised database. A database-only education check on a candidate from an uncovered institution returns "no record found," which is indistinguishable from a false credential without direct registrar contact.
Employment: UAN/PF records confirm contribution history but do not verify designation, reporting line, or reason for separation. Small and mid-sized employers in India, Pakistan, and Bangladesh frequently lack structured HR departments, making phone and email the only viable channels for confirmation.
Criminal records: India has no unified national criminal database accessible to private verification firms. District-level court searches, often requiring physical visits or local agent networks, remain the standard. Database aggregators cover only a fraction of courts and carry significant lag in updates.
Southeast Asia: Philippines, Vietnam, Indonesia
Philippines: The Commission on Higher Education (CHED) maintains a database of recognised programmes, but individual degree verification requires direct contact with the university registrar. Diploma mills remain a documented concern, and database presence alone does not confirm institutional legitimacy. NBI (National Bureau of Investigation) clearances for criminal checks require direct application and cannot be reliably queried via API.
Vietnam: There is no centralised degree verification database. Universities maintain their own records, and verification must go through the institution's academic affairs office. Many institutions only respond to formal written requests with an official company letterhead and authorisation from the candidate.
Indonesia: The Dikti (Higher Education) database provides some coverage, but affiliated institutions under private universities are frequently missing. Employment verification in Indonesia relies heavily on direct HR contact, as no national employment database exists.
Eastern Europe: Poland, Romania, Ukraine
Poland: University degree verification typically requires direct contact with the dziekanat (dean's office). While Poland's POL-on system provides some centralised data on higher education, access for private verification firms is restricted. Employment verification depends on direct employer contact, as ZUS (social insurance) records are not accessible for private BGV purposes.
Romania: The Ministry of Education maintains degree records, but verification requests from foreign entities require notarised authorisation. Response times from Romanian universities can extend to several weeks without persistent follow-up.
Ukraine: Ongoing conflict has disrupted institutional archives in some regions. Verification of credentials from eastern Ukrainian universities may require alternative evidence chains, including cross-referencing with the EDBO (Unified State Electronic Database on Education) and direct contact with relocated administrative offices.
Latin America: Mexico, Brazil, Colombia
Mexico: The Registro Nacional de Profesionistas provides a database of registered professional degrees, but coverage is limited to federally registered titles. State university degrees and technical certifications often require direct contact with the institution. IMSS (social security) records can confirm employment tenure but not role or designation.
Brazil: Degree verification must go through the issuing institution's secretaria acadêmica. MEC (Ministry of Education) recognition confirms the programme exists but not that a specific individual graduated. Employment records through eSocial provide tenure data but require employer authorisation for access.
Colombia: The SNIES (National Higher Education Information System) covers recognised institutions, but diploma fraud involving unrecognised institutions is a documented risk. Employment verification relies on direct employer contact, as there is no centralised employment database accessible for BGV purposes.
What happens when depth is missing
Shallow verification does not fail loudly. It fails silently. The report says "verified," the candidate is hired, and the gap in evidence sits dormant until something forces a closer look. Three scenarios illustrate what that looks like in practice.
Scenario 1: Fraudulent credentials slip through
A candidate claims an MBA from a mid-tier private university in India. The dashboard vendor queries NAD. The university is not in NAD's coverage. The vendor queries a commercial aggregator. No record found. The vendor marks the check as "unable to verify (no database coverage)" or, worse, finds a partial match on a similarly named institution and marks it "verified."
Eighteen months later, internal audit discovers the candidate never attended the institution. The degree certificate was purchased from a document forgery operation. The BGV report provided no protection because no one at the university was ever asked to confirm the credential. The database either missed it or matched it incorrectly. The exposure is now the client's: the candidate occupies a role that required the qualification, and the hiring decision relied on a verification report that looked complete but contained no institutional evidence.
Scenario 2: Regulator samples your verification reports
A financial services regulator conducts a thematic review of hiring controls across regulated entities. They request the full BGV documentation for 25 randomly selected employees. For each, they ask: what was the source of the verification? Who at the institution confirmed the credential? What method was used? Is the confirmation documented?
If your vendor operated at Level 1 or 2, the answers are: "government database," "automated system," "no institutional contact," and "system log." The regulator treats these as unverified hires. Your compliance posture now depends on how many of the 25 sampled employees fall into this category. At 40% or above, the regulator may require a remediation programme, including re-verification of all current employees at your cost.
Scenario 3: Re-verification costs after vendor switch
You switch from a database-only vendor to an operator-led programme. The new vendor reviews sample reports from the prior engagement. They find that 45% of "verified" employment checks contain no institutional contact record, and 30% of education checks were resolved by database match alone on institutions with known coverage gaps.
The new vendor recommends re-verifying all current employees whose checks were resolved below Level 3. For a workforce of 2,000, with an average of 3 checks per employee, the re-verification cost is roughly equivalent to running the original programme again at 35% to 40% of scope. The commercial impact: you paid your original vendor for verification you are now paying a second time to actually receive.
Operator-led depth in practice
The difference between a dashboard model and an operator model is not just "more databases." It is a fundamentally different approach to building evidence. The operator model treats every check as a case that requires a defensible evidence chain, not a query that requires a match.
Dashboard model
- Default method: database query. Institutional contact only if no database match is found.
- Verification status based on match/no-match binary.
- No escalation chain when databases have gaps.
- Report lists "source: national database" without specifying which database, query date, or match criteria.
- Discrepancies between candidate claims and database records may go undetected if the match is close enough.
Operator model
- Default method: direct institutional contact. Databases are a reference input, not the primary source.
- Verification status based on institutional confirmation with named contact, method, and timestamp.
- Structured escalation chain: email, then phone, then alternative contact, then field visit.
- Report documents every source independently: database result, HR contact name, phone number used, confirmation date, and any discrepancies found.
- Analyst judgment applied to resolve discrepancies, with documented reasoning and cross-reference evidence.
The operator model costs more per check. That is true, and it is the honest trade. What it buys is a report that contains actual evidence rather than database echoes. When your compliance team, your regulator, or your internal auditor pulls that report, the evidence is there: who confirmed it, how, when, and what they said. That is the difference between a verification and a lookup.
Five questions to ask about verification depth
These questions reveal whether a vendor's verification programme operates at database level or institutional level. They work without needing access to sample reports.
- For each check type in my programme (education, employment, criminal, address), what is your primary verification method: database query, institutional contact, or both? Describe the default path, not the exception path.
- What percentage of your education checks are resolved by database match alone, without direct registrar contact? Break this down by corridor (India, Philippines, etc.).
- When a database has no coverage for a specific institution, what happens next? Walk me through the escalation chain for a non-covered university.
- For employment checks, do you contact the employer's HR department directly in every case? If not, under what conditions do you skip HR contact and rely on database records only?
- Can you show me a sample verification report that includes the full evidence chain: source name, contact method, contact person, confirmation date, and cross-reference documentation?
Frequently asked questions
Database-only verification is when a background check vendor resolves a credential claim by querying one or more databases and marking the check as "verified" based on a match result. No one at the issuing institution (university, employer, licensing board) is contacted directly. The verification output is a system log showing that a database returned a record consistent with the candidate's claim. This method is fast and inexpensive, but it produces weak evidence that may not survive audit scrutiny, particularly in corridors where database coverage is incomplete.
Ask for a sample report and look for specific evidence of institutional contact: the name of the person at the institution who confirmed the credential, the method used (phone, email, portal), the date of confirmation, and any reference number issued by the institution. If the report lists only "verified via national database" or "confirmed through public records" without naming a specific institutional contact, the check was almost certainly resolved by database query alone. A vendor that uses direct contact will be able to produce this evidence for any case in your programme.
Multi-source triangulation means verifying a single credential claim against two or more independent sources and reconciling any differences. For example, an employment check might combine HR department confirmation (primary source) with UAN/PF contribution records (secondary source) and payslip review (tertiary source). If all three align, the evidence is strong. If they conflict (say, PF records show a different start date than HR confirmed), the analyst investigates the discrepancy and documents the resolution. Triangulation catches inconsistencies that any single source, including institutional contact alone, might miss.
Field verification (a physical visit to the institution, employer, or address) is necessary when remote channels are exhausted or unreliable. Common scenarios include: non-responsive institutions that do not answer email or phone queries, address verification in areas where no digital infrastructure exists, small employers that have no HR department or formal verification process, and high-risk cases where discrepancy flags require physical document inspection. Field verification adds cost and time, but it produces the strongest possible evidence and is sometimes the only viable method in certain corridors.
Verification depth requirements vary dramatically by country due to differences in database coverage, institutional responsiveness, and fraud prevalence. In India, roughly 60% of universities are not in the NAD, making database-only education checks unreliable for the majority of candidates. In the Philippines, degree verification requires direct university contact because no centralised verification database exists. In Poland, ZUS records are not accessible for private verification, so employment checks must go through employer HR directly. A vendor using the same database-first approach across all corridors will produce widely varying levels of evidence quality, strongest in countries with robust databases and weakest precisely where the fraud risk is highest.
Not always. Deeper verification takes longer on individual checks where institutional response is slow. However, the total programme TAT is often comparable because operator-led programmes avoid the rework cycle that database-only vendors face: re-opening cases when databases return inconclusive results, escalating to institutional contact after a database-only attempt fails, and re-verifying checks that were flagged by audit. The honest framing is that deeper verification invests time in the right place (building evidence upfront) rather than in the wrong place (managing the consequences of shallow verification later).
A defensible verification report should contain, for each check: the source (who or what confirmed the credential), the method (phone, email, portal, field visit), the date of confirmation, the contact person's name and designation (for institutional contact), any reference numbers issued, the specific data points confirmed (tenure dates, designation, degree title, graduation year), any discrepancies found between the candidate's claim and the institutional response, and the resolution of those discrepancies. If the report contains only a result ("verified" or "unable to verify") without this supporting evidence, the report is not audit-defensible.
Our default operating level is Level 3 (direct institutional contact) for every check. Database queries are used as a reference input, not as a closure mechanism. Every check follows a documented escalation protocol: primary institutional contact, then secondary contact if unresponsive within 48 hours, then field verification if warranted. Each step is logged with source, method, timestamp, and analyst name. Cases close only on evidence or on documented reasonable exhaustion, defined per corridor. Our quality assurance process samples completed reports and verifies that the evidence chain is complete before the report ships. The result is a programme that operates at Level 3 by default and escalates to Level 4 when the corridor, institution, or risk profile demands it.
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 showing how institutional contact and escalation work in practice.
- India deep dive: corridor-specific detail on NAD coverage, registrar response patterns, and per-check TAT ranges.
- Compliance brief: how verification depth feeds into audit defensibility and the evidence standards regulators expect.
- TPRM self-assessment: pre-scored vendor evaluation framework including depth and methodology questions.
Next Step
Test your programme's verification depth.
Run the TPRM readiness scorecard to see how deeply your current vendor actually verifies, or read the full compliance brief.