Synthetic Passport: Complete Guide

Search "synthetic passport" and the results split into two unrelated topics: an AI training dataset and a financial-crime tactic. If you're building or evaluating an identity-verification model, the first meaning is the one you need — the second isn't your problem, and confusing the two wastes research time.

A synthetic passport, in the machine-learning sense, is a passport image and its accompanying metadata generated by a model rather than scanned from a real document — built to look and function like a genuine one, with no real person's data inside it. This guide covers how that data gets built, what a usable dataset actually contains, where it's applied, and where its limits still are. 

About the author: Elizabeth Karnaukhova

Datamarket Project Manager. Leads synthetic passport and ID document generation projects

A synthetic US passport: generated holder, no real person’s data.

Key takeaways

• A synthetic passport is a model-generated passport image with metadata and no real person’s data. It is unrelated to synthetic identity fraud, which mixes stolen PII with invented details.
• Teams use it for two reasons: GDPR Article 9 treats passport biometrics as a special category, and real collections rarely cover enough countries, lighting conditions and document wear.
• Most passport-specific generation is hybrid: a generated face, generated text fields and an ICAO 9303 MRZ are composited onto a real empty template. Pure GAN, VAE or diffusion output struggles to get the MRZ and layout right.
• A dataset is only as useful as its labels: per-field bounding boxes and ground-truth text, plus capture-condition metadata for stratified splits.
• Open benchmarks such as MIDV-500, MIDV-2020, IDNet and SynID suit prototypes. Production systems usually need a custom mix of countries, capture conditions and attack types.
• Synthetic data does not replace real-world validation. Test on a real holdout set and break accuracy down by attack vector, not one aggregate score.

What is a synthetic passport?

A synthetic passport is built to do one job: stand in for a real passport in a training or test pipeline without exposing a real person's data. Every face, name, document number, and signature on it is generated — there is no human behind any of it. Structurally, though, it matches a genuine document closely enough to be useful: the same field layout, the same machine-readable zone format, the same range of print quality and wear.

That distinction matters because real passports sit inside personally identifiable information (PII) — among the most tightly regulated data categories that exists. A synthetic passport is built specifically to exclude PII, which is what lets teams train and test models on it without the legal exposure of collecting and storing genuine documents.

Two fields consume this data almost exclusively: identity-verification systems that validate a document during onboarding, and document-fraud research that studies how forged or manipulated passports differ from genuine ones.

Synthetic passport vs. synthetic identity fraud

The name collides with an unrelated term from financial crime, and it's worth resolving immediately. Synthetic identity fraud is a crime category: a fraudster combines a real person's stolen details — most often a Social Security number — with invented details like a fabricated name or date of birth, to build a credit identity that "fabricates a person or entity in order to commit a dishonest act for personal or financial gain," in the Federal Reserve's working definition¹. A synthetic passport, in the AI/ML sense this guide covers, sits at the opposite end of the data-origin axis: it contains zero real PII. Every field is generated, not stolen.

One is built to keep models honest. The other is what those models are increasingly trained to catch.

Why synthetic passport data exists

Real passport collections are some of the hardest training data to assemble legally. Acquiring enough of them — across countries, lighting conditions, document damage, and fraud types — to train an identity-verification model that generalizes well is rarely possible within the law, let alone within budget.

Passport scans fall under biometric and identity data, which the EU's GDPR treats as a special category requiring an explicit legal basis under Article 9 before it can be processed at all². Most organizations cannot legally retain or share scanned passports outside narrow, specific consent. Synthetic data sidesteps that constraint by construction — there's no real subject whose consent or retention rights are in question. 

On an identity-verification project covering more than 100 countries, real passport images were closed to us for collection and for transfer alike, so the data was reproduced under controlled parameters instead: templates, text fields, faces and physical artifacts generated separately, then combined into more than 100,000 images with no personal data in any of them.

A second, separate motivation sits behind the regulatory one: real-world passport collections tend to be skewed toward whichever demographics and document conditions were easiest to gather, which is where bias enters — covered in the next section.

Privacy regulations and real passport data scarcity

GDPR Article 9 classifies biometric data processed to uniquely identify a person — which includes the photo on a passport — as a special category, prohibited by default unless a specific legal basis applies, such as explicit consent or substantial public interest². The UK, California (CCPA), and most jurisdictions with comparable privacy law follow the same logic even where the statute's wording differs: identity-document data isn't free to collect just because someone is willing to hand over a scan.

That legal exposure, not generic collection cost, is what made passports the document type most worth synthesizing. A held real-passport dataset carries retention risk for as long as it exists; a synthetic one carries none, because there's no PII in it to retain. Teams that need volume and geographic diversity for identity-verification training get both without taking on the liability of holding genuine documents at scale.

Reducing bias and covering edge cases

The second motivation is coverage, not just legality. Real-world passport collections skew toward whichever demographics, lighting conditions, and document ages were easiest to gather, and a model trained on that skew underperforms on everyone outside it — a well-documented failure mode in identity verification and face-based systems generally.

Synthetic data lets a team specify the gaps directly: glare on a laminate, a creased data page, an uncommon country template, a decade-old print run with faded ink. 

Real collections rarely contain enough of these conditions to train against; a generation pipeline can produce as many as the spec calls for, deliberately, rather than hoping a large enough real sample happens to include them.

How literal that spec gets is worth seeing. In our printed UK passport set a single document yields 96 images: three capture angles — 0°, 25°, 45° — across four lighting conditions, four backgrounds and two shooting distances. Every cell in that grid exists because it was asked for, which is the part a real collection cannot promise.

One synthetic passport, four backgrounds; lighting, angle and distance held fixed.

The background is the condition a phone capture never holds fixed: the same page against a plain wall, a wood-grain desk, street paving and a pile of other documents is four different cropping problems for the model that has to find the document edge first — and on the last one, the right document among several.

How synthetic passports are generated

Two broad approaches produce a synthetic passport, and most production pipelines combine both rather than picking one. The first is pure generative synthesis: a model learns the visual distribution of real documents and samples new ones from scratch. The second is hybrid template compositing: a real, empty document layout gets populated with generated elements — face, text fields, machine-readable zone — instead of generating the whole image from nothing.

Generative Adversarial Networks are the method referenced most often in the research behind this technique, particularly for the photo component³. Variational Autoencoders, and more recently diffusion models, also see production use, especially where sample diversity matters more than pixel-level photorealism. The next two sections walk through each path.

Generative Adversarial Networks and Variational Autoencoders

A Generative Adversarial Network (GAN) pairs two networks against each other: a generator that produces candidate images, and a discriminator trained to tell generated images apart from real ones. Both improve through the contest — the generator gets better at fooling the discriminator, the discriminator gets better at catching it — until, ideally, the generator's output is indistinguishable from genuine data, including to the discriminator itself³. That adversarial loop is what made GANs the default starting point for synthetic face and document generation.

A Variational Autoencoder (VAE) takes a different route: it learns a compressed, continuous representation of the training distribution and samples new points from that learned space rather than competing against a discriminator⁴. VAEs tend to produce smoother, more diverse output than GANs at some cost to sharpness — a trade-off that matters when a dataset needs broad coverage more than razor-sharp realism on any single image. Diffusion models, which build an image by reversing a noise process step by step, have started to take over the face-generation step specifically, for similar diversity reasons.

Hybrid template-based compositing pipelines

The method documented most recently for passport-specific generation doesn't generate a whole document from noise — it composites one. SynID, published in 2025, builds on an empty ICAO-compliant passport template and populates it with a synthetically generated face, programmatically filled subject metadata, and a machine-readable zone (MRZ) constructed to ICAO 9303 format, then layers in realistic imperfections such as edge blur and lighting variance⁵. 

That hybrid approach exists because compositing onto a real layout solves a problem pure generation struggles with: getting structural details — MRZ character spacing, check-digit placement, security-pattern position — right by construction, rather than hoping the generator learned them implicitly. The MRZ follows a fixed ICAO 9303 format, commonly two lines of 44 characters on a passport booklet, built from uppercase letters, the filler character "<", and check digits computed from the surrounding fields⁶ — exactly the kind of rigid, rule-governed structure that's easier to generate programmatically than to learn from pixels. 

Run in production, the pipeline gains a stage the papers compress. Ours fills the text fields with language models rather than a script, because names, document numbers and issuing-authority strings have to read plausibly across scripts and languages instead of merely occupying the right boxes; the rest of the sequence matches what SynID describes — layouts for more than 100 countries, generated portraits blended into each one, then fonts, seals, holograms, background noise, glare and scanning artifacts varied per document.

Same pipeline, different holders: generated portraits and text fields. 

Why the compositing stage earns its cost is clearest from what it replaced. One client had been editing templates by hand, masking personal fields and inserting text from spreadsheets at random. The output looked artificial: it reproduced none of the variability of genuine documents — layouts, fonts, lighting, textures, wear — and the model trained on it generalized poorly, returning frequent false positives in verification.

Anatomy of a synthetic passport dataset

A usable synthetic passport dataset is more than a folder of images. Each record typically packages the biometric photo region, printed text fields (name, nationality, dates, document number), the machine-readable zone, background and security-pattern elements, and structured metadata — country, document type, gender, and capture or lighting condition.

That metadata is what makes the dataset usable for more than one task. A document-classification model needs the country and document-type tags; a field-extraction model needs per-field ground truth; a robustness test needs the condition tags to stratify performance by lighting or print quality rather than reporting one blended accuracy number. Computer-vision pipelines built for document understanding consume exactly this structure — image plus per-field, per-document metadata — rather than a raw image alone.

Common data fields and labeling conventions

Labeling conventions are what turn a generated image into training data a model can actually learn from. A typical record includes a bounding box per field for OCR training, a ground-truth text value for each field, country and document-type tags, and condition metadata — lighting, angle, background — used to build stratified train and test splits.

A minimal field-level record looks roughly like this:

{

  "document_type": "passport",

  "country": "FRA",

  "fields": {

    "surname": {"bbox": [120, 88, 310, 116], "text": "MARTIN"},

    "mrz_line_1": {"bbox": [40, 540, 560, 566], "text": "P<FRAMARTIN<<JEAN<<<<<<<<<<<<<<<<<<<<<<<<<<<"}

  },

  "condition": {"lighting": "low-glare", "angle": 8}

}

Concrete field names and bounding-box coordinates like this — not an abstract schema description — are what actually make a dataset spec evaluable before a team commits to it.

A shipped set carries more of them than a minimal example suggests. That set records a passport and sample ID, class, country, gender and age group, then angle, distance, resolution, camera, light condition, background and capture timestamp. The last seven are the ones a stratified split actually runs on: without them, performance by lighting or by capture angle is not a question the dataset can answer.

Applications across identity verification and fraud prevention

Synthetic passport data feeds two practical pipelines, both downstream of the generation methods above: identity verification, including Know Your Customer (KYC) checks during onboarding, and document-fraud or presentation-attack detection. The first teaches a model what a genuine document looks like and how to extract its fields; the second teaches it what a forged or replayed one looks like by comparison.

Financial institutions and other regulated entities must verify a customer's identity before establishing a business relationship under the customer due diligence standards set by the Financial Action Task Force, and digital identity systems — including document-capture verification — are an accepted way to meet that requirement when the verification method can be demonstrated and risk-assessed⁷. The two sections below split this into the onboarding side and the fraud/border side.

KYC and digital onboarding

During digital onboarding, a user photographs their passport with a phone camera, and a model has to do two things fast: confirm the document is structurally genuine, and extract the fields needed for the KYC check. Training that model on real customer passports would mean retaining exactly the PII the onboarding flow is trying to verify in the first place — the scarcity-and-privacy problem covered earlier, applied to a live financial product.

Synthetic passport data lets a team cover the country and document-type variety a global user base actually presents, without a single real customer's document in the training set. 

Presentation attack detection and border security

The second application is harder and more research-active: presentation attack detection (PAD), which distinguishes a genuine document capture from a printed copy, a screen replay, or a manipulated original, in both remote verification and physical border checkpoints. ISO/IEC 30107-3 sets the standard testing methodology for PAD, defining the two error rates that matter: the Attack Presentation Classification Error Rate (APCER), how often an attack is misclassified as genuine, and the Bona Fide Presentation Classification Error Rate (BPCER), how often a genuine document is misclassified as an attack⁸. 

Synthetic passport datasets purpose-built for PAD, like SynID, exist specifically to supply attack and bona fide examples at the volume a standard like this requires to test against⁵. 

A print-attack sample: printed synthetic page, 45°, dim light. 

In our printed sets every image carries the attack label: a synthetic page printed, then photographed on a phone at an angle and in poor light — the print presentation a PAD model has to reject. 

The same anti-spoofing logic that secures face recognition — print attacks, replay attacks, multi-device testing — extends directly to document capture; it's the same attack surface, with a passport instead of a face as the target. Unidata's work on biometric spoofing-attack simulation across print and replay attacks is the same testing logic applied to faces rather than documents.

Existing synthetic passport datasets and benchmarks

Three dataset names come up repeatedly in the literature ML and fraud teams actually cite. MIDV-500 is an early identity-document benchmark: video clips covering 50 document types — including 14 passport types — each printed and filmed under five different shooting conditions⁹. Its successor, MIDV-2020, expanded document diversity and scope for the same recognition task¹⁰.

IDNet takes a different angle: 837,060 synthetically generated identity-document images across 20 document types from 10 U.S. states and 10 European countries, each paired with one or more fraud patterns — text-field replacement, face morphing, portrait substitution — built specifically because MIDV-500 and similar sets don't include enough fraud variation to train a fraud-detection model against¹¹. SynID, covered above, fills the presentation-attack-specific gap neither of the other two was built for⁵.

Comparing open-access and commercial datasets

Open-access sets like MIDV-500 and IDNet are free, reproducible, and well-documented — and limited by design: fixed subject counts, fixed country coverage, and document templates that may not match a specific production region. 

A team building for markets the open sets don't cover has to either extend an open dataset or commission custom generation matched to the country mix, document conditions, and fraud types they actually need.

That's the same build-or-buy trade-off teams face with any specialized dataset, not unique to passports: ready-made sets get a project started fast, but production deployments tend to converge on a custom specification once the open option's coverage gaps show up in real evaluation. Ready-made datasets suit prototypes and proof-of-concept work; production identity-verification systems, with their specific country and document-type requirements, are usually a custom-collection case. Where the shortfall is country coverage on its own, a commercial set spanning more than 100 countries closes it without a bespoke build; where it is capture conditions, the per-country printed sets are the closer fit.

Evaluating quality, realism, and compliance

Three checks decide whether a synthetic passport dataset is fit for purpose, and none of them is "does it look real." First, structural compliance: does the MRZ format, face-crop ratio, and field layout actually match ICAO 9303, or does it just look plausible to a human eye⁶? Second, privacy verification: does the dataset actually contain zero real PII, confirmed rather than assumed — the entire compliance argument for using synthetic data collapses if a generation pipeline accidentally memorized and reproduced a real training example. Third, transfer performance: does a model trained on the synthetic set perform comparably on held-out real or independently generated documents, which is the practical test of whether the realism gap, covered next, is small enough to matter for the task.

We consistently see that teams investing in tiered quality control — one labeling pass, a reviewer check, then a separate QA audit — catch the compliance and labeling errors that a single annotation pass misses, and that holds for synthetic-document review the same way it holds for any other annotation pipeline: the structural check is only as reliable as the process verifying it, not the generation method that produced the image.

Limitations of synthetic passport data

Synthetic passport data is not a complete substitute for real-world documents, and treating it as one is the most common mistake teams make. Generated documents can still carry a realism gap against genuine ones — texture, print artifacts, and security-feature fidelity that a generator never quite reproduces — and a model trained only on synthetic data can underperform on real-world conditions the generator never learned to produce, because it never saw them.

Synthetic data and augmentation are genuinely valuable for expanding coverage and addressing class imbalance — that's the entire argument for using them, covered earlier in this guide. But edge cases from real-world environments are irreplaceable: a generator trained on a finite set of real examples can interpolate between them, not invent conditions it never observed. That's why production identity-verification pipelines typically validate against a real-world holdout set rather than relying on synthetic data alone for the final accuracy check.

Skipping that step has a measurable cost. A biometric client of ours trained its presentation-attack detection entirely on synthetic data for two years; the system cleared every internal check and failed iBeta pre-checks each time, with latex and high-quality 3D masks bypassing detection consistently. Folding in 32,000+ recordings made on the target certification device closed the gap in two months, and the part that located the residual misses was an accuracy breakdown by attack vector rather than an aggregate score.

The generation method matters too. A Generative Adversarial Network trained on a non-diverse real sample can reproduce — not fix — the same demographic or document-condition skew the synthetic approach was meant to solve³, which is why the training data behind the generator needs the same scrutiny as the training data it's meant to replace.

Conclusion and next steps

Real passports are among the most regulated, hardest-to-source data in identity verification, and no real collection covers every edge case. GANs, VAEs, diffusion models, and template compositing each close part of that gap, so KYC and PAD research now treat synthetic passports as a standard input, though not as a replacement for real-world validation.

Before adopting a dataset, check country and document-type coverage, ICAO 9303 compliance if structure matters, and whether its attack patterns match what your model must catch. If the gap is print, replay, or mask attacks rather than layouts, tell us which vectors the model has to catch, and the set can be scoped to them.