Document checks or government database checks: which does your onboarding need?

Reading an ID document is enough when no government record is available to check it against, or when the decision you are making is low-stakes and reversible. Wherever a record exists and the account can move money, you want the government record, because a document check can only tell you that an ID looks genuine, while a database check tells you the identity was actually issued.

Neither check, on its own, tells you the applicant is the owner of that identity. That comes from matching a live face against a photo you can trust, and the choice of photo is where many onboarding designs quietly go wrong.

What does each check actually prove?

The two checks answer different questions, so it helps to separate them before comparing.

A document check reads the ID from a photograph. It extracts the printed fields, reads the machine-readable zone or barcode where there is one, confirms the document type matches what the applicant selected, and checks things like expiry and whether the typed details match the printed ones. Its conclusion is: this document is consistent with a genuine document of this type, and here is what it says.

A government database check takes an identifier, usually the ID number, and asks the issuing authority's record whether it exists and what it holds: the name, date of birth and often a photograph. Its conclusion is: an identity with this number was issued, and here are the details on file.

NIST's identity proofing guideline, SP 800-63A-4 (opens in a new tab) (July 2025), draws the same line. It calls the issuer, or a service with direct access to the issuer's data, an authoritative source, and treats validation against one as stronger than inspecting a document image. It also expects anyone relying on optical inspection to test it "in conditions that are substantially similar to the operational environment", which is a polite way of saying that document reading is only as good as the photos your users actually take. NIST is a US standard, but the distinction is general.

Where does each one fail?

The failure modes are more useful than the strengths, because they tell you what to pair each check with.

Two rows need emphasis.

A number-only database check proves the number, not the person. A BVN or NIN check returns a real record if the number is real. If the applicant typed their cousin's number and date of birth, the record still comes back. The check becomes an identity verification only when a live selfie is compared against the photograph the record holds.

A selfie matched to the photo printed on a document proves little if the document is fake. A forger prints their own face on the forgery. The selfie matches, because it is the same face. On a document-only check, a face match confirms the applicant resembles the document; it cannot confirm the document belongs to a real identity.

How does coverage change the choice?

Often you do not get to choose. Government records are reachable in some countries and not others.

In Myaza Trust Identity Verification, government database verification runs in five markets: Nigeria, Ghana, Kenya, South Africa and Côte d'Ivoire. Nigeria also supports number-only IDs (BVN, NIN and vNIN), which need no document scan at all. For every other country, passports, driving licences and national ID cards verify by document capture, and the database step is unavailable: the per-ID govDbCheck flag is always false there. The full list is on the KYC coverage page and in the Countries and ID types documentation.

The result carries the difference forward. A pass backed by the government record reports assurance level gov_db; a pass from the document alone reports document. A passport can reach the stronger chip tier when a mobile app reads and authenticates its chip.

Which photo should the selfie be compared with?

This is the design decision that matters most, and it follows directly from the failure modes above.

The strongest comparison photo is one the applicant could not have supplied: the photograph held on the government record, or the portrait on an authenticated passport chip. The weakest is the photo printed on the document the applicant is holding.

Myaza Trust compares the selfie with the strongest photo the verification holds, in that order. Where the workflow enables it, a document ID with no record photo and no chip can fall back to the printed photo, and the result says so: facialMatchSource is gov_record, chip or document. A printed-photo match never raises the assurance level, and a decision rule can send those matches to review. The workflows documentation describes the setting.

A decision guide for onboarding design

These scenarios are illustrative, not recommendations for any specific regulated activity.

• A savings app onboarding Nigerian customers. Use a number-only ID (NIN or BVN) with a live selfie matched against the record photo. The database proves the identity exists; the face ties the applicant to it. Adding a document scan here adds friction without adding much evidence.

• A lender onboarding a Ghanaian customer with a Ghana Card. Capture the card and run the database check. You get the printed details from the card, the issued details from the record and, where the record holds one, a photo for the face match. Mismatches between the card and the record are themselves a signal.

• A marketplace onboarding sellers in France and Kenya. The Kenyan seller can reach gov_db. The French seller verifies by document only. Decide in advance whether a document-tier seller gets the same payout limits, or a lower limit until their history builds.

• A crypto platform with high-value customers anywhere. Route passport holders through a mobile flow that reads the chip. A chip that authenticates against its issuing country is the strongest evidence available for countries with no reachable database.

When is a document check enough?

A reasonable rule of thumb:

1. Use the government record wherever one exists for any account that can hold or move money.

2. Always bind the record to a live face, matched against the record photo or an authenticated chip portrait, not only the printed photo.

3. Accept document-only passes where no record exists, and decide in writing what a document-tier customer may do before more evidence builds up.

4. Branch on the evidence, not only the verdict. Store the assurance level and facialMatchSource with every outcome, and route the weaker combinations to review or to lower limits.

What counts as sufficient evidence for customer due diligence differs by jurisdiction and by licence, and this article is general information rather than legal advice. Whatever your regulator requires, the question to ask of every flow is the same: which part of this result came from a source the applicant could not have made up?