KYC & Identity Verification Test Data
Test identity verification pipelines with realistic but safe synthetic identities and corroborating documents.
KYC pipelines do not verify documents in isolation; they cross-check them. A name on one document has to match the name on another, an address has to corroborate, and stated income has to be consistent with the tax forms behind it. Testing that logic requires a set of documents that genuinely belong to the same person — which is exactly what SymageDocs produces, because every document in a multi-form job is filled from one simulated identity. The W-2, the 1040, and the address on both agree because they originate from the same underlying person, not because someone edited fixtures until they matched.
The problem
Identity verification is the one place where realistic test data is hardest to obtain and most necessary. Real customer documents are the most sensitive data a financial institution holds, and using them for development is usually prohibited outright. The alternative most teams fall back on is hand-maintained fixtures, which corrode quickly: someone updates the name on the W-2 fixture and forgets the 1040, so the cross-check test starts passing for the wrong reason. Random generators are worse, because incoherence is their default — the whole point of a KYC pipeline is to detect mismatches, and a generator that emits mismatches at random cannot tell you whether your matcher works or your data is broken.
The SymageDocs approach
SymageDocs generates the person first and the paperwork second. One simulated identity carries a name, date of birth, government identifiers, an address anchored to a real ZIP code and its city, an employer with an EIN and address, a household, and income derived from that occupation's BLS wage distribution and the state and metro area they live in. Every requested form is then filled from that single identity, and a cross-form coherence pass runs afterwards on multi-form jobs. When you need the negative cases, the simulation exposes coherence modes that deliberately break the correlations: shuffled mode permutes every field across identities — names and addresses along with the figures, not just the financial ones — preserving each field's distribution while destroying the cross-field agreement your matcher is supposed to catch.
What you actually get
- Corroborating document sets — W-2, 1040, W-9, and onboarding forms — all filled from one simulated identity.
- Identities with structurally valid government identifiers that follow real generation rules rather than a recognizable test prefix.
- Addresses anchored to real ZIP codes and their actual cities, so geographic validation has something meaningful to check.
- Deliberately incoherent negative cases via shuffled and random coherence modes, for testing that your matcher actually fails when it should.
- A tabular CSV of the underlying identity data in every bundle, giving you the expected answer to assert against.
How it works
Generate the identity
A complete fictional person is simulated: biographical details, government identifiers, geography, employment with a real-shaped employer, household composition, and financials derived from the occupation's BLS wage distribution adjusted for state and metro area. Filing status is enforced against household composition, so a married-filing-jointly identity actually has a spouse.
Request the corroborating set
Ask for several form types in one job. The identity is generated once and reused across every form in the sample, which is what makes the documents corroborate rather than merely coexist.
Choose coherence or incoherence
The default coherence mode keeps everything consistent. Shuffled mode permutes every field across identities — identity fields as well as financial ones — so per-field distributions survive but cross-field correlations do not. It needs a quantity above one to do anything: a permutation of a single identity is the identity, so a shuffled job of one document is accepted and returns perfectly coherent output. Request a batch. Random mode works at a different level: each form in an item is filled from its own independently generated identity, so every document is internally coherent but the set no longer describes one person. Those are your negative test cases.
Assert against known values
The bundle's CSV and per-instance JSON record exactly which values landed on which document, so a verification test can assert the expected match or mismatch instead of inspecting PDFs by hand.
By the numbers
| Metric | Value | Detail |
|---|---|---|
| Coherence modes | 3 | Coherent by default, plus shuffled and random for generating deliberate mismatches. |
| Fields on a Form 1040 | 141 | Two pages of the 2024 layout, the income document most KYC flows reconcile against. |
| Fields on a W-2 | 45 | The 2025 single-page layout. Denser multi-copy and packet variants of the same form also ship. |
| Real customer records used | 0 | Every identity is sampled from distributions rather than derived from a real person. |
Field and page counts are read from the shipped form definitions in the SymageDocs form library. Library-size figures count every definition the API can generate; the public form reference pages under /forms document a curated subset of them, so that page shows a smaller number. Output-format availability reflects the current API contract; the ML export formats (BIO, YOLO, COCO, Donut) sit behind a feature flag that is not enabled in production, so treat them as a preview rather than a generally available option.
Who this is for
Fintech and banking teams building or testing onboarding and identity verification flows, income verification and underwriting pipelines, and the QA organizations that have to regression-test those flows continuously without touching customer records. It also suits vendors selling verification software who need demonstration and evaluation data they can hand to a prospect without a data agreement.
Where SymageDocs is not the right tool
SymageDocs generates documents, not identity infrastructure. It does not produce photo identification, passports, or driver's licenses, it does not generate biometric or liveness data, and it has no connection to any credit bureau, sanctions list, or government verification service — so it cannot test the parts of your flow that call those systems. It is also emphatically not a tool for defeating identity verification: the output is generated for testing your own pipeline, and the documents describe people who do not exist. If your gap is the biometric or database-lookup leg of KYC rather than the document leg, this addresses the wrong half of the problem.
Relevant forms
Frequently asked questions
- Do the documents in a set actually corroborate each other?
- Yes, when you request them in a single multi-form job. The system generates the identity once and fills every requested form from it, so the name, date of birth, identifiers, address, and employer are shared across the set and the financial figures reconcile between forms. A cross-form coherence pass runs after generation. Requesting each form as a separate job would give you unrelated identities, which defeats the purpose.
- Can I generate mismatched documents to test the failure path?
- That is exactly what the non-default coherence modes are for. Shuffled mode permutes every field across identities — the name and address shuffle alongside the figures, so identity fields disagree too — and each field keeps a realistic distribution while the cross-field agreement is destroyed. That is a realistic mismatch rather than obvious garbage. One precondition worth knowing before you write the test: shuffling permutes values between identities, so it requires a quantity greater than one. A shuffled job requesting a single document is accepted without error and comes back fully coherent, which reads as your matcher passing when it was never given a mismatch to catch. Random mode breaks the set at a different level: each form gets its own independently generated identity, so every document is internally consistent but they describe different people. Testing that your matcher fails when it should is as important as testing that it passes when it should.
- Are the Social Security numbers and EINs valid?
- They are structurally valid: generated identifiers follow real-world generation rules for their component parts and are randomized within those rules, so they pass format and structural checks. SSNs in particular follow the SSA's own assignment history — an area number derived from the birth state for identities born before 1996, and a randomized area number for later ones — which is what makes them survive a validator instead of failing at the first digit. They deliberately do not carry a recognizable synthetic prefix, because a marker like that would let a system under test pass by detecting the marker rather than by doing the verification. It is worth being exact about what that means for privacy. No identifier is derived from, or checked against, any real person's record — the whole identity is drawn from distributions — so nothing in the output is anyone's data, and there is no source record behind it to trace back. What we will not claim is that a generated number can never coincide with an issued one: because the values are drawn from the same structurally valid space real identifiers occupy rather than from a reserved test range, collisions are possible and at volume some are likely. Treat a generated SSN as unowned rather than as unassignable, and do not use one as a live lookup key against a real system.
- Can I use this to test document fraud detection?
- For the data-consistency dimension, yes, and the coherence modes are the mechanism — inconsistent figures across a document set are a genuine fraud signal. For visual tampering detection it is a weaker fit, because the generator produces cleanly rendered documents rather than manipulated ones, and it does not simulate splicing, font substitution, or retouching artifacts. If you are training a model to spot pixel-level tampering, you will need to introduce those manipulations yourself.
- Does the address data correspond to real places?
- Addresses are anchored to real ZIP codes paired with their actual cities and states, so geographic validation and address normalization have something coherent to work against. Demographics follow state-level rates rather than ZIP-level ones — a synthetic population placed in New Mexico carries a different ethnicity mix from one placed in Vermont — and wages are adjusted by state and by metro, micropolitan, or rural classification. The street addresses themselves are generated. The intent is that an address looks and validates like a plausible address, not that it points at a specific real building.
- How do I know what the expected verification result is?
- Every bundle includes a tabular CSV of the underlying identity data and per-instance JSON recording exactly what was placed on each document. Your test asserts against those known values rather than against a document you have manually inspected, which is what makes the suite maintainable — when you regenerate the corpus, the expected values regenerate with it instead of drifting away from your fixtures.