Proof of Citizenship: How Didit Detects Citizenship from Identity Documents

Identity verification has historically answered one question: who is this person. A name, a date of birth, a government-issued photo ID, a biometric match. Enough to open an account, pass AML screening, and move on.

In 2026, regulators across multiple jurisdictions are adding a second question: what is this person's citizenship. The US Treasury Department is drafting an executive order requiring banks to collect citizenship data from customers. The EU's eIDAS 2.0 framework is making nationality a first-class attribute in digital identity wallets. Voter registration, gaming licenses, cross-border financial services, government benefits, and immigration-sensitive industries are all pushing nationality verification from nice-to-have to mandatory.

This post explains how Didit handles proof of citizenship — which documents are supported, how extraction works, what authenticity checks are performed, and how the output integrates with the rest of the KYC stack.

What Counts as Proof of Citizenship

Citizenship is not a single data point. It is derived from document evidence, and the accepted evidence varies by country. A few patterns hold globally:

• Passports are the strongest proof. Every country that issues passports limits issuance to citizens (and a small set of exceptions like refugee travel documents). The document itself is issued under the ICAO 9303 standard, which means it has a machine-readable zone, a structured visual zone, and — for modern editions — an NFC chip containing the same data signed by the issuing authority.
• Naturalization and citizenship certificates prove acquired citizenship. These are typically paper documents issued by federal or national authorities. In the US, the relevant forms are N-550/N-570 (Certificate of Naturalization) and N-560/N-561 (Certificate of Citizenship).
• Birth certificates prove citizenship by birth in jurisdictions where birthright citizenship applies. Formats vary wildly — in the US alone, every state, territory, and many counties issue their own.
• Consular reports of birth abroad (CRBA / FS-240 in the US, equivalent documents in other countries) cover citizens born outside their country of citizenship.
• National ID cards imply citizenship in countries where the national ID is issued only to citizens (most of the EU, parts of Latin America, most of the Middle East). In countries where residents can also hold national IDs (eg. some Gulf states, some EU long-term resident cards), the national ID alone does not establish citizenship.

A verification provider that supports only passports cannot serve customers who never got one. Around 52% of US adults, and significantly higher percentages in much of Latin America and Southeast Asia, do not hold a passport. A provider that supports only driver's licenses cannot serve any citizenship verification requirement at all — a driver's license proves lawful presence in most jurisdictions, not nationality.

Didit's document library covers all of the above, across 220+ countries and 14,000+ document types.

The Verification Flow

From the customer's perspective, the flow is one continuous session on a phone or desktop. Under the hood, six layers run in parallel.

Layer 1: Document Capture

The customer is prompted to photograph the document. The capture SDK handles framing, glare detection, focus, and low-light correction. It rejects scans that are too blurry, too dark, or cropped. On passports, it specifically prompts for the page with the MRZ and, if the device supports NFC and the passport has a chip, offers to tap the passport against the phone for chip read.

For birth certificates and naturalization certificates — where no MRZ or chip exists — the capture flow guides the customer to photograph the full document on a contrasting surface, and can accept multiple pages for documents that span more than one side.

Layer 2: Document Classification

Before any field extraction, the document is classified: type, country, issuing authority, issue year range. Classification runs on a model trained across the 14,000+ document library, which means it can distinguish a Texas birth certificate from a Georgia birth certificate, a 1998-era Certificate of Naturalization from a current one, and a US passport book from a US passport card.

Classification output drives downstream processing. Different document types have different field schemas, different security features, and different authenticity signals to check.

Layer 3: Field Extraction

OCR extracts the structured fields for the identified document type. On an ICAO passport, that means name, date of birth, nationality, passport number, issuing country, expiry date, sex, place of birth, and the MRZ check digits. On a Certificate of Naturalization, it means A-number, name, date of birth, country of former citizenship, date of naturalization, and certificate number. On a US state birth certificate, it means name, date of birth, place of birth, parents' names, and registration details.

The extraction model is tuned per document type. Running a generic OCR over a Mississippi birth certificate produces garbage — the typography is unusual, the security background is noisy, the field layout varies by year of issue. Document-specific extraction is the difference between 97% and 60% automation rates.

Layer 4: Authenticity Checks

This is where most of the fraud prevention happens. Depending on the document, the system runs:

• MRZ integrity check — the machine-readable zone contains check digits computed from the encoded data. A forged or altered passport fails this check.
• NFC chip verification — if the chip is present, the system reads the signed data group, verifies the issuer signature against the country's trust list (eg. the ICAO PKD), and compares the chip data to the visual zone.
• Security feature detection — holograms, UV features, microprinting, intaglio, ghost images. The model looks for the specific features the issuing authority uses for that document version.
• Template matching — the document is compared to reference templates for the issuing authority in the same year range, looking for font mismatches, layout deviations, and color inconsistencies.
• Tampering detection — splice detection, copy-paste artifacts, photo substitution, field-level edits. This catches cases where a legitimate document has been modified after issuance.
• Image forensics — detection of digital-only documents, screenshot artifacts, and rendering signatures from known forgery tools.

For birth certificates and other low-security documents, authenticity checks rely more heavily on template matching and tampering detection, because the documents themselves have fewer physical security features. This is a structural weakness of the document class, not of the verification — the correct mitigation is to pair birth-certificate-only verification with additional signals (SSN verification, address history, device risk) rather than to pretend that a clean OCR of a birth certificate equals strong proof.

Layer 5: Biometric Match and Liveness

The document photo is compared to a live selfie captured from the customer's device. The liveness layer confirms that the selfie is a live human being, not a photo of a photo, a deepfake, a 3D mask, or a replay attack. The face-match layer compares the biometric features and returns a match score.

For citizenship documents that do not include a photo — US birth certificates, certain naturalization certificates, some older national IDs — the biometric step runs against a separate, photo-bearing ID collected in the same session. The customer uploads both documents; the biometric is matched to the photo ID; the citizenship evidence is tied to the same verified identity.

Layer 6: Output

The API returns a structured verification record:

• Document type, country of citizenship, extracted fields
• Authenticity score and the specific checks that passed or failed
• Biometric match score and liveness result
• Overall decision (approved, review, declined) with reason codes
• Tamper-evident audit trail with hashed document images, timestamps, and system version

The record integrates with sanctions screening, PEP and adverse media checks, and ongoing monitoring — the full KYC stack — via the same API.

What Citizenship Detection Actually Returns

The most common integration pattern is a single call that produces a verification session, and a webhook that delivers the structured result when complete. A simplified example of the citizenship portion of that result:

{
  "status": "approved",
  "document": {
    "type": "certificate_of_naturalization",
    "country_of_issue": "US",
    "form_number": "N-550",
    "extracted_fields": {
      "a_number": "A-xxxxxxxxx",
      "certificate_number": "xxxxxxxx",
      "name": "JANE DOE",
      "date_of_birth": "1985-06-12",
      "country_of_former_citizenship": "MX",
      "date_of_naturalization": "2014-09-18"
    }
  },
  "citizenship": {
    "status": "US",
    "acquisition": "naturalization",
    "evidence_document_type": "certificate_of_naturalization",
    "confidence": 0.98
  },
  "authenticity": {
    "overall_score": 0.96,
    "checks": {
      "template_match": "pass",
      "security_features": "pass",
      "tampering": "pass",
      "image_forensics": "pass"
    }
  },
  "biometric": {
    "liveness": "pass",
    "face_match_score": 0.93
  }
}

The same shape applies across document types. For a US passport, the citizenship field would carry status: "US", acquisition: "birth_or_unspecified", evidence_document_type: "passport" and the full MRZ and NFC results in the authenticity block. For a birth certificate, the citizenship field carries the derived status, the state of issuance, and the lower confidence score that reflects the weaker security profile of birth certificates as a document class.

Downstream systems — core banking, compliance case management, data warehouse — consume the structured fields and route accordingly.

Edge Cases That Matter

Real citizenship verification has to handle a long tail of cases that a casual implementation misses.

Dual citizenship. A US citizen who is also a Mexican citizen presents a Mexican passport. The passport legitimately proves Mexican citizenship. It does not disprove US citizenship. If the use case requires confirming US citizenship specifically, the flow has to accept additional US-issued evidence in the same session.

Stateless persons and refugees. Travel documents issued under the 1951 Refugee Convention or the 1954 Stateless Persons Convention look like passports but explicitly do not confirm citizenship. Didit identifies these documents distinctly and surfaces the correct status instead of treating them as proof of citizenship of the issuing country.

Recently naturalized citizens. A customer who naturalized in the last 60 days may not yet have a US passport. They will have a Certificate of Naturalization. The flow has to accept the certificate as primary citizenship evidence, not insist on a passport.

Citizens born abroad. A US citizen born in Germany to US parents has a Consular Report of Birth Abroad (CRBA / FS-240), not a US birth certificate. The flow has to recognize the CRBA as citizenship evidence.

Name changes and document mismatches. A customer who naturalized under one name and later legally changed their name presents a Certificate of Naturalization with the old name and a current passport with the new name. The verification has to tie the two together without rejecting either.

Historical documents. A Certificate of Naturalization issued in 1987 looks different from one issued in 2024. Template matching and authenticity checks have to span the issuance history, not just the current format.

A verification stack that silently fails on these cases is not actually solving the citizenship problem — it is solving a simplified subset while pushing the rest to manual review. Didit's library includes historical and edge-case document variants by design.

Privacy and Data Handling

Citizenship is sensitive data. Most privacy frameworks treat nationality and immigration status as a protected category alongside race, religion, and political opinion. Storing it incorrectly creates a second compliance problem while trying to solve the first.

Didit's posture on citizenship data:

• Data minimization. The platform returns only the citizenship fields the customer configured. A lender that only needs to confirm "is this person a US citizen, yes/no" can receive a boolean, not the full document data.
• Controller/processor boundary. Didit acts as processor. The customer (the bank, fintech, platform) is the controller. The legal basis for processing sits with the customer, and Didit's DPA reflects that.
• Encryption at rest and in transit with key rotation.
• Retention controls configurable per customer — minimum required for regulatory obligations, then purged.
• Audit logging of every access, for both internal accountability and regulator subpoena response.
• GDPR, LGPD, CCPA, and APPI-aligned data handling with region-specific residency options where applicable.

The goal is to let the customer meet their regulatory obligation without inheriting a new one from the verification layer.

Integrating Citizenship Verification

The fastest path to production is through the hosted verification flow: one API call to create a session, a URL the customer visits on their phone, a webhook with the result. The flow handles capture, OCR, authenticity, biometric match, and result delivery in a single session.

For teams that need deeper customization — white-labeled UI, custom branching logic, specific document type restrictions — the SDK and direct API give full control over each layer.

Typical integration patterns:

• Banks and credit unions: citizenship capture triggered during account opening and, under the new US rule, during re-verification of existing accounts. Result feeds the core banking system and the AML case management queue.
• Fintechs: citizenship capture at account upgrade or at the threshold where regulations require it (eg. when a customer crosses a monthly volume limit that triggers heightened KYC).
• Crypto exchanges: citizenship capture for jurisdictions where the operator is licensed only to serve citizens or residents of specific countries.
• Gaming and iGaming operators: citizenship capture where licensing requires it, combined with age verification in the same flow.
• Government service providers: citizenship capture for benefits eligibility, tied to pre-defined evidence standards.
• Cross-border services: citizenship capture to route the customer to the correct jurisdictional compliance pipeline.

What This Unlocks

A citizenship verification layer, done well, is not a checkbox. It is a new shape of identity data that downstream systems can act on. Banks can route customers to the correct onboarding track based on citizenship. Exchanges can enforce jurisdictional restrictions without relying on IP-based geolocation. Governments can verify benefit eligibility without paper-based processes. Platforms can comply with emerging citizenship-gated regulations without rebuilding their KYC stack.

The US executive order under discussion in April 2026 is one forcing function. It will not be the last. The direction of regulatory travel is toward identity verification as a richer data product — identity, nationality, sanctions status, risk profile, ongoing monitoring — delivered in a single flow that works in under two minutes on a phone.

Didit's bet, since day one, has been that the right way to serve that is with broad document coverage, structured output, pay-per-check pricing, and an API surface that integrates cleanly into whatever system the customer already runs. Citizenship detection is a natural extension of that bet.

---

Didit verifies citizenship, identity, and sanctions exposure for banks, fintechs, crypto platforms, and government services. 14,000+ document types, 220+ countries, 48+ languages, $0.30 per verification, no minimums. Start for free or talk to the team.