Last updated: October 2026

Document verification and database verification answer two different questions about an applicant. Document verification checks that an identity document looks genuine and belongs to the person presenting it. Database verification checks that the name, date of birth, address and identification number an applicant enters exist and agree with trusted records. Neither check proves what the other proves, so a bank, lender or fintech has to decide when one is enough and when it needs both.

This guide explains how each method works, what each one proves and does not prove, where each one fails, what the bank Customer Identification Program (CIP) rule says about them, and how to choose between them.

TL;DR

• Document verification proves that a credential looks authentic and matches its holder. It does not prove that the identity behind the credential has any history.

• Database verification proves that an identity's details exist and agree with records such as a credit bureau file. It does not prove that the applicant is the person those records describe.

• Document checks fail on well-made forgeries and AI-generated documents and selfies. Database checks fail on stale records and on synthetic identities built to match.

• The CIP rule, 31 CFR 1020.220, lets a bank verify identity through documents, non-documentary methods or both, under risk-based procedures it writes down.

• Most programmes use a data match for lower-risk applicants, ask for a document when the data does not resolve or the risk is higher, and combine both with device and behavioural signals where the stakes are highest.

• Neither method establishes intent. A verified identity can still belong to a fraudster.

The short answer

Document verification proves that an identity document is genuine and belongs to the person presenting it. Database verification proves that the identity details an applicant gives exist and match trusted records. The first tests the credential and its holder; the second tests the data.

Neither method proves both things, and neither proves intent. A verification check confirms that a claimed identity exists and matches its documents at a moment in time. It does not establish that the applicant means well, and it does not establish that the identity was not assembled specifically to pass the check.

The bank CIP rule treats the two as separate verification methods. Under 31 CFR 1020.220(a)(2)(ii), a bank's procedures must describe when it will use documents, non-documentary methods or a combination of both. That is why identity programmes are risk-based: one method for some applicants, the other for some, and both for the riskiest.

How document verification works

Document verification, sometimes called ID document verification, is the process of checking a government-issued identity document and confirming that the person presenting it is its rightful holder. Most remote document verification software runs four steps in sequence.

1. Capture. The applicant photographs or scans the front and back of a driver's licence, passport or national ID card. The software checks image quality first, because glare, blur or a cropped edge makes every later check unreliable.

2. Authenticity checks. The software compares the document against the known layout of that document type and looks at its security features, such as fonts, holograms, microprint and the placement of each field, for signs of tampering or a template that does not match.

3. Data extraction and consistency. Optical character recognition reads the printed fields, and where the document has a machine-readable zone or barcode, the software reads that too. The two readings should agree with each other, with the document's own rules (an expiry date in the future, for example) and with what the applicant typed.

4. Matching the holder. The applicant takes a live selfie, and a face match compares it with the photo on the document. A liveness check tests whether the selfie came from a live person in front of the camera rather than a photo, a screen or an injected video stream.

The US National Institute of Standards and Technology describes identity proofing in comparable stages in NIST SP 800-63A-4, published final in July 2025. In that framework, document verification covers two of them: validating the evidence (is the document genuine, accurate and current) and verifying the applicant (is this person the one the evidence describes). NIST's guidelines are written for federal agencies; they are a widely used reference, not a rule binding on banks.

How database verification works

Database verification is the process of matching the identity details an applicant enters against independent records. It is also called data-based or non-documentary verification, and when it runs through an API at account opening it is often called electronic identity verification.

The applicant enters a name, date of birth, address and an identification number, usually a Social Security number in the United States. The verification service compares those details with sources such as credit bureau files, public records and other commercial data, and returns whether each element matches, partly matches or does not match. Nothing is photographed and the applicant does not need a document in hand.

A chief compliance officer at a bank described the common pattern: check the applicant against a credit bureau first, require the name, date of birth and address the applicant entered to match the bureau file, and switch the applicant to another method, often a document, when they do not.

Government sources are part of the picture too. The Social Security Administration's electronic Consent Based SSN Verification (eCBSV) service lets permitted financial institutions and their service providers check, with the number holder's written consent, whether a Social Security number, name and date of birth match SSA records. It returns a yes or no, identifies which element does not match, and flags a death record if there is one.

Like every database check, eCBSV confirms that the elements match. It does not confirm that the applicant is the person they belong to.

In NIST SP 800-63A-4's terms, database verification is attribute validation: checking that the core attributes a person claims hold up against authoritative or credible sources.

What each one proves, and what it does not

Database verification proves that an identity's details exist and agree with one another in trusted records. It does not prove that the person typing them in is the person they describe. Anyone who holds a real person's name, date of birth, address and Social Security number can pass a database match on that person's identity.

Document verification proves that a credential looks genuine and, with a face match, that the person presenting it resembles the photo. It does not prove that the identity on the document has a credit file, an address history or any existence outside the document. A well-made fake for an invented person can pass the document checks while matching nothing anywhere.

The two methods are complementary because each covers the other's blind spot. A database match without a document leaves the question of who is applying open. A document without a database match leaves open whether the identity is real.

Neither method establishes intent. An applicant who passes both checks has shown that a real-looking identity and a real-looking credential line up. The applicant has not shown that they mean to use the account honestly, which is why account opening decisions also draw on device, behavioural and application signals.

Where document verification fails

Document verification fails when a forgery is good enough to pass the checks. Template-based authenticity checks compare a document against the known layout of its type, and a well-made fake built on the right layout can clear them. A consumer fraud strategy lead at a telecom put it this way: "Our current id verification solution is going to be obsolete because it's template based and we're seeing more and more instances where bad actors are able to create fake ids that pass these template based checks." The same lead described seeing the same face on several different IDs, a pattern that no single document check can see because each document passes on its own.

Generative AI has made realistic fakes cheap. The chief executive of a lender described a recent case: "Other thing that popped up this morning is we got an AI generated license submitted as a stipulation wow, and our human eyes caught it, but our technology needs to catch that for them." A risk policy manager at a digital lender made the same point more bluntly, describing AI that can mimic documents so closely that a reviewer cannot tell the fake from the original.

The selfie step is attacked as well. A senior KYC team lead at a property-management software company said: "We also have had people send us a selfie holding their id, yep full fledged holding their id is fake completely AI with AI." Liveness checks, injection attacks and deepfakes are a subject of their own; our guide to the best deepfake detection tools covers how those checks work and how to evaluate them.

Documents requested as a step-up are a target too. A fraud strategy and analytics manager at a digital bank described applicants who, when asked for a driver's licence or an account statement, forge the document and send it back. FinCEN's November 2024 alert on deepfake media, FIN-2024-Alert004, lists identity documents that are inconsistent with each other, or a photo inconsistent with the applicant's other identifying information, among its red flags.

Where database verification fails

Database verification fails genuine applicants when the records are out of date. Credit bureau files hold the address a person last gave a lender, not necessarily the address where they live now. The chief compliance officer described earlier summed up the problem: "I don't know of anybody who calls the credit bureau and say update my information." People who have recently moved, or who have little credit history, fail the match for reasons that have nothing to do with fraud, and each failure sends a legitimate applicant to a slower path.

Database verification also passes identities that were built to pass it. The Federal Reserve defines synthetic identity fraud as follows: "Synthetic identity fraud (SIF) is the use of a combination of personally identifiable information (PII) to fabricate a person or entity in order to commit a dishonest act for personal or financial gain." The Federal Reserve Bank of Boston has described how such identities are assembled from fragments of different real people's information, such as one person's account number, another's driver's license number and a child's Social Security number. Each fragment is real, so a lookup on it can come back as a match. Our guide to detecting synthetic identities covers the signals that catch them.

A lookup keyed on one identifier can also miss a near-duplicate. A VP of risk and compliance at a credit union described two records with the same name and date of birth but different Social Security numbers, one of them presented with a fake ID that closely resembled the real one. The document looked right, and a search by Social Security number would not have connected the two records. Staff caught it only because an employee happened to search by exact name.

What the CIP rule says about documents and data checks

The bank Customer Identification Program rule, 31 CFR 1020.220, requires a bank to obtain, at a minimum and before opening an account, the customer's name, date of birth (for an individual), address and an identification number. Under 1020.220(a)(2), the programme must include "risk-based procedures for verifying the identity of each customer" sufficient for the bank to "form a reasonable belief that it knows the true identity" of the customer.

The rule names both methods. Section 1020.220(a)(2)(ii) requires the procedures to describe when the bank will use documents, non-documentary methods, or a combination of both.

• Documentary methods, 1020.220(a)(2)(ii)(A). For an individual, (A)(1) gives as examples an unexpired government-issued identification evidencing nationality or residence and bearing a photograph or similar safeguard, such as a driver's license or passport.

• Non-documentary methods, 1020.220(a)(2)(ii)(B). (B)(1) gives as examples contacting a customer; independently verifying identity by comparing information from a consumer reporting agency, public database or other source; checking references with other financial institutions; and obtaining a financial statement.

The rule does not say non-documentary methods must be used for every customer. Under 1020.220(a)(2)(ii)(B)(2), the non-documentary procedures "must address" five situations: an individual who cannot present an unexpired government-issued photo ID; documents the bank is not familiar with; an account opened without obtaining documents; a customer who opens the account without appearing in person; and other circumstances that increase the risk that the bank cannot verify identity through documents. Remote account opening falls squarely within that list.

Examiners read the rule the same way. The FFIEC BSA/AML Examination Manual's Customer Identification Program section describes verification through documents and verification through non-documentary methods, and states that a bank using non-documentary methods must have procedures for them.

When to use which, and when to use both

The right method depends on the applicant's risk and on what the first check returns. The CIP rule leaves the choice to the bank's risk-based procedures, and most programmes settle on three tiers.

• A data match alone for lower-risk applicants whose details resolve cleanly against trusted records. This is the lightest step for a genuine applicant and the one most remote account openings start with.

• A document when the data does not resolve or the risk is higher. A partial match, a thin file, an address that does not agree, or a riskier product calls for evidence the database cannot supply. This is the bureau-first, document-as-fallback pattern the chief compliance officer described.

• Both, plus other signals, where the stakes are highest. For high-value or high-risk accounts, a document and a database match together, combined with device intelligence, behavioural signals and checks across other applications, close more of the gaps than either method alone. Cross-application checks are what catch the same face on several IDs or the same details behind several applicants.

The channel changes the default as well. At a branch, staff can inspect the document in person. A VP of risk and compliance at a credit union described frontline staff looking at the ID and hoping it looks right, then pulling a database verification report. Remote opening removes the in-person inspection, which is one of the situations the rule's non-documentary procedures must address.

The order in which checks run, and when to escalate from one to the next, is a design decision in its own right. Our guide to building a KYC compliance programme covers the CIP programme as a whole and how to sequence verification checks, and our guide to KYC fraud detection covers the fraud signals that sit alongside them. Choosing an identity verification provider to run the document and data checks themselves is a separate evaluation, with its own criteria.

Document verification vs. database verification at a glance

The table summarises the trade-off: each method proves what the other cannot, and each fails where the other is strong.

Where Oscilar fits

Oscilar sells an onboarding and risk platform, and it is the decision and orchestration layer around document and database checks rather than a provider of either. Oscilar does not perform document verification, liveness or Social Security number checks itself. It calls the third-party identity verification and data providers a bank or fintech chooses, and decides what to do with their results.

Oscilar's consumer onboarding page describes the role in its own words: "Orchestrate KYC checks and enhanced identity checks for a true 360° view of each applicant." Onboarding workflows adapt to each applicant's risk profile, and "Step-Up Verifications: Trigger enhanced due diligence and additional verification steps when it's needed." That is how the tiers above run in practice: a data match first, a document request when the data does not resolve or the risk rises, and the results combined with other signals before a decision.

Those other signals matter because neither verification method establishes intent. The same page describes how teams "Leverage advanced signals such as device intelligence, behavior biometrics and data enrichments" alongside the verification results. Oscilar provides a full audit trail per decision with stored reasoning, and human-in-the-loop by design. Oscilar has auto model monitoring covering data drift, feature drift and concept drift, plus outcome KPIs measured by segment, and the platform is specified for sub-100ms decisions.

Frequently asked questions

What is document verification?

Document verification is the process of checking that a government-issued identity document, such as a driver's licence or passport, is genuine and belongs to the person presenting it. Document verification software captures an image of the document, checks its security features and layout, extracts and cross-checks its data, and usually compares the document photo with a live selfie.

What is database verification?

Database verification is the process of matching the identity details an applicant enters, typically name, date of birth, address and an identification number, against independent records such as credit bureau files and public records. Database verification confirms that the details exist and agree with each other. Database verification does not confirm that the applicant is the person those details describe.

Does the CIP rule require a document?

No. The bank CIP rule, 31 CFR 1020.220(a)(2)(ii), lets a bank verify identity through documents, non-documentary methods or a combination of both, as its risk-based procedures describe. The bank's non-documentary procedures must address situations such as a customer who cannot present an unexpired government-issued photo ID or who opens an account without appearing in person.

Can a synthetic identity pass database verification?

Yes. A synthetic identity combines pieces of personal information, often including real ones, to fabricate a person, so a database lookup on those pieces can return a match. Catching synthetic identities takes signals beyond the match itself, such as how the identity's records were built and whether its details appear across other applications.

Is electronic identity verification the same as database verification?

Mostly, yes. Electronic identity verification usually means verifying an applicant's details against databases through an online check, which is database verification. Some providers also use the term for remote document and selfie checks, so ask which checks a given electronic identity verification service runs.

Document verification and database verification work best together. Database verification shows that an identity's details are real and consistent; document verification shows that a credential is genuine and in the right hands. A risk-based programme uses the data match where it is enough, asks for a document where it is not, and decides with both and with signals neither check can see. To see those checks run in one onboarding flow, read about how Oscilar orchestrates identity checks in onboarding.