Why we built WealthSchema on synthetic data instead of anonymized real data

The first question every prospective buyer asks is the same: why not just buy anonymized data? It is cheaper. The records are real. The relationships are real. And every fintech engineer has at least once stitched together a "production-like" dataset by stripping names off a CSV their compliance team handed them.

We tried that path in 2024. Two months in, three of our test households were uniquely identifiable from public LinkedIn pages plus a single ZIP code. The next month a fourth re-identified through a 13F filing. We threw out anonymization and rebuilt on a fully synthetic foundation that month.

This article is the case for why every team that handles wealth data — for testing, for analytics, for backtesting — should do the same.

The math of re-identification

The classic result is from Latanya Sweeney (2000): 87% of Americans are uniquely identified by the combination of ZIP code, date of birth, and gender. Add a single income band and the number rises above 99%. Anonymized financial data routinely retains all four of those fields because models depend on them.

For a wealth dataset to be useful for backtesting, it has to retain more than ZIP + DOB + gender. It has to keep account balances, tax-filing status, employer industry, household composition, and occupation. Each of those is itself a re-identification vector.

What "anonymization" actually means in practice

In practice, the term "anonymized" covers four distinct techniques, each with a different leakage profile.

The honest middle ground for wealth data is k-anonymity at k≥5 plus aggressive top-coding (truncating any account balance above the 95th percentile, generalizing any ZIP smaller than 1,000 households). What you get is data that is no longer realistic — it cannot be used to test edge-case logic like UHNW household carryforward losses or single-state ZIP-level sales-tax calculations. The exact things your engine needs to handle correctly are the things k-anonymity has to file off.

Synthetic data, properly built, has none of these problems

A correctly generated synthetic household has no causal link to a real person. There is no joinable identifier. The financial statements are internally consistent — net worth = assets minus liabilities to the dollar — but the underlying entity does not exist in any registry, payroll system, custodial account, or property record.

“

The promise of anonymized data is that you can have realistic edge cases AND privacy guarantees. You can't. Synthetic data trades a small loss in 'realness' for a zero-leak guarantee — and we found the realness loss was much smaller than we expected.

The realness gap shrank with model quality. Companion piece: synthetic data fidelity privacy utility tradeoff. Our 2024 prototype, generated on GPT-4-class models, had 18% of households flagged by reviewers as obviously synthetic ("a 27-year-old with a $4M brokerage account, no income, no inheritance"). The 2026 v4 corpus, generated through the staged pipeline with explicit archetype constraints and cross-field validation, has that number under 2% — and the remaining flags are usually compositional issues we want to surface anyway.

Fair-lending and disparate-impact exposure

Anonymized real data carries a second risk that has nothing to do with re-identification: it carries the biases of the historical underwriting decisions that produced it.

A model backtested against historical lending decisions inherits the demographic skew of those decisions. Even if individual records are anonymous, the joint distribution of credit decisions, ZIP codes, and income bands encodes patterns that fail Reg B / ECOA fair-lending audits. The federal regulators have made clear that "we tested against anonymized real data" is not a defense.

This is a real reason fintech teams have moved to synthetic data even when their privacy posture didn't strictly require it. The race_ethnicity and religion fields in our schema are explicitly conditional overlays — never present in the default household — for exactly this reason.

What we ship instead

WealthSynth households are generated against 71 archetypes with hardcoded population targets. Every household passes a strict validation gate before promotion: arithmetic identities, archetype fidelity, internal consistency, and bundle-overlay reconciliation. The deliverable is a structured JSON profile per household — no rendered documents, no LLM-authored narrative prose. Profiles are generated deterministically from archetype templates and applicable bundle overlays, with an LLM-as-judge gate catching residual quality issues; total LLM spend on a full 1,451-household corpus refresh is a fraction of the cost of a single re-identification incident.

The bottom line

We built WealthSchema because every team we talked to had the same problem: they wanted realistic test data, the only "realistic" data was anonymized real data, and the privacy posture of anonymized real data did not survive any honest threat model. Synthetic was the only path that made the privacy story trivial — and once we got the realness gap below 2%, it stopped being a trade-off at all.

If your engine handles tax lots, equity grants, retirement income sequencing, or any of the edge cases real underwriting actually depends on, you need data with all the structure and none of the leakage. See synthetic financial data primer for the basics. That is the job WealthSchema exists to do.