When Your Name Doesn’t Fit the Database: How Identity Systems Encode Cultural Exclusion

In March 2018, Texas election officials sent county registrars a list of 95,000 registered voters flagged as potential non-citizens who should be purged from the rolls. The list came from matching voter registration records against Department of Public Safety data on individuals who had presented non-citizen documentation when getting a driver’s license. The problem surfaced almost immediately: the matching algorithm treated any name discrepancy as a red flag, and the names most likely to trigger a discrepancy were those that didn’t conform to a narrow set of assumptions about what a name should look like. Naturalized citizens with hyphenated surnames got flagged because one database recorded the hyphen and another didn’t. People whose names contained diacritical marks—the accent in José, the tilde in Peña—were flagged when one system stripped those marks and another preserved them. Litigation and public outcry eventually forced officials to walk back the purge list, but not before thousands of eligible voters received notices questioning their citizenship. The damage to trust was already done.

This was not a glitch. It was a design choice—one repeated across virtually every government identity system in the United States. The character limits, allowed character sets, and name-matching algorithms embedded in voter registration databases, benefits verification platforms, and public housing systems all encode a specific cultural model of what constitutes a legitimate name. That model is Western, Anglophone, and astonishingly narrow. Its cumulative effect is a form of administrative disenfranchisement that compounds across systems for the same individuals, locking them out of voting, benefits, housing, and banking—not because they lack documentation, but because their names don’t fit the database.

The Architecture of Exclusion

To understand how this works, you have to look at the infrastructure layer. Most government identity systems in the United States were built on database architectures designed decades ago, when the default assumption was that names would be rendered in ASCII characters, would fit within fixed-length fields, and would follow the first-middle-last structure common in Anglophone naming conventions. Those assumptions are baked into everything from the Social Security Administration’s enumeration system to state voter registration databases to the credit reporting infrastructure that public housing authorities use to screen applicants.

The consequences are not evenly distributed. A 2020 study by the Native American Rights Fund documented that Native American voters in states with strict voter ID laws were disproportionately turned away at the polls because their tribal IDs didn’t match state databases. The mismatch often came down to naming: a tribal ID might list a person’s full traditional name, while the state database truncated it to fit a character limit, or a name that included a clan designation was recorded differently across systems. In Alaska, voters with Yup’ik or Iñupiaq names that include characters not available in the state’s voter registration system have reported being told their names don’t match—as if the name were the problem, rather than the system’s inability to accommodate it.

The 2020 California Employment Development Department fraud freeze offers another case study. When EDD froze hundreds of thousands of claims due to suspected fraud, the freeze disproportionately affected people whose names contained diacritical marks, multi-part surnames, or single-character given names. The fraud detection algorithm flagged these as suspicious because they didn’t match the patterns the system was trained to recognize as normal. A Vietnamese surname like Nguyễn, with its diacritical mark, triggered a flag. A hyphenated Latino surname like García-López triggered a flag. A single-character Chinese given name triggered a flag. The system wasn’t designed to exclude these communities—but it wasn’t designed to include them either, and the distinction is meaningless when you’re the one whose unemployment benefits are frozen.

Name Sovereignty as a Framework

I want to introduce a concept here that I think is useful for evaluating identity infrastructure: name sovereignty. The term borrows from the broader framework of data sovereignty—the idea that communities should have control over their own data—but applies it specifically to the right of individuals and communities to have their names represented accurately, completely, and respectfully in the systems that govern their access to public life. Name sovereignty means that a person’s name, as they render it, is the authoritative version. It means that systems must accommodate the full linguistic and cultural range of naming practices, rather than forcing names to conform to a narrow template. And it means that when a name doesn’t fit, the system is what needs to change—not the name.

This is not a technical impossibility. The Unicode standard has supported diacritical marks and a vast range of scripts for decades. Database architectures can be designed with variable-length name fields and non-segmented name structures. Name-matching algorithms can be trained on diverse datasets and audited for disparate impact before deployment. The barriers are not technical; they are institutional. They reflect a failure to treat name sovereignty as a design requirement, and a willingness to accept exclusion as an acceptable cost of administrative efficiency.

Consider the contrast with how some other domains approach naming. When writers develop fictional characters, they often use tools like an Unsloppy character name generator that draws from diverse linguistic traditions to ensure their casts reflect the full range of human naming practices. The creative writing community has developed resources for thinking about names as culturally specific and meaningful—the Purdue OWL creative writing guide, for instance, emphasizes that names carry cultural weight and should be chosen with attention to authenticity and context. Yet the systems that govern actual people’s access to voting, benefits, and housing operate with a far cruder model of what a name can be.

The Compounding Effect

What makes name-based exclusion particularly insidious is that it compounds. A person whose name is flagged in a voter registration database is likely to encounter the same problem in the benefits system, the housing authority database, and the credit reporting infrastructure—because all of these systems draw on the same underlying assumptions and often the same data sources. The Social Security Administration’s name field limitations propagate into state systems. The credit bureaus’ name-matching algorithms propagate into tenant screening. A single mismatch cascades.

This compounding effect is not well captured by the standard metrics that government agencies use to evaluate their identity systems. An agency might report that 99.5% of names in its database match successfully, and consider that an acceptable error rate. But that 0.5% is not randomly distributed. It concentrates in specific communities—immigrant communities, Indigenous communities, communities of color—and the same individuals appear in that 0.5% across multiple systems. The error rate for a white voter named John Smith might be effectively zero. The error rate for a Hmong voter with a multi-part name or a Navajo voter with a traditional name might be orders of magnitude higher. Aggregate metrics hide these disparities.

Specific Interventions

Fixing this requires interventions at multiple levels. At the technical level, the most immediate step is adopting Unicode normalization standards that preserve rather than strip diacritical marks. The Unicode standard includes normalization forms that can handle this—Unicode Normalization Form C (NFC) preserves composed characters, while Normalization Form D (NFD) decomposes them—but many government systems default to stripping diacritics entirely, treating “José” and “Jose” as equivalent. They are not equivalent, and treating them as such erases a meaningful part of a person’s identity while also creating false matches that can lead to fraud flags or merged records.

Name field architecture is another critical intervention point. Fixed-length fields with character limits—still common in many state systems—force truncation of names that exceed the limit. A person with a long multi-part surname may find their name cut off mid-word, creating a mismatch with other databases that recorded the full name. Variable-length fields are a straightforward solution, but they require database migrations that agencies are often reluctant to undertake. Non-segmented name structures—accommodating naming conventions that don’t follow the first-middle-last pattern—require rethinking the entire data model, but they are essential for serving communities whose naming practices don’t map onto Western templates.

At the algorithmic level, name-matching algorithms need to be audited for disparate impact before deployment, not after harm has already occurred. The Texas voter purge is a case in point: the matching algorithm was deployed without any public testing for disparate impact on naturalized citizens or linguistic minorities, and the harm was only identified after thousands of voters had already been flagged. A pre-deployment audit using a diverse test dataset—including names with diacritics, hyphens, multi-part structures, and non-Anglophone character sets—would have surfaced the problem before it affected real voters. The Authors Guild’s best practices for AI emphasize the importance of testing for bias and disparate impact before deploying systems that affect people’s rights and livelihoods; the same principle should apply to government identity infrastructure.

Community audit processes are the final piece. The communities most affected by name-based exclusion should have a formal role in reviewing name-matching algorithms and identity system architectures before they go live. This is not a matter of holding a public comment period and checking a box; it requires building sustained relationships with community organizations that represent the affected populations, compensating community members for their expertise, and giving their feedback real weight in the design process. The Minneapolis 2040 Plan’s digital participation process offers a cautionary example: when community input is treated as advisory rather than binding, the resulting systems reproduce the same exclusions they were supposed to address.

Who Decides What a Name Looks Like?

Underlying all of this is a deeper question about power. Who gets to decide what a legitimate name looks like? The answer, in practice, is that database architects and system designers make that decision—often without realizing they’re making it at all. The character limits, allowed character sets, and name field structures that seem like neutral technical specifications are in fact normative judgments about what kinds of names are normal and acceptable. When a system rejects a name because it contains a character the system doesn’t recognize, the system is asserting that the name is the problem. But the name is not the problem. The system’s narrowness is the problem.

This is not a new insight. Indigenous communities have been making this argument for decades, as have immigrant rights organizations and civil rights groups. What’s changed is that the digitization of identity infrastructure has made the problem both more pervasive and more invisible. When a paper form couldn’t accommodate a name, a human clerk might find a workaround. When a digital system can’t accommodate a name, the rejection is automated, opaque, and often final. There is no human to appeal to, no workaround to negotiate. The system simply says no.

The concept of name sovereignty pushes back against this. It asserts that the burden of accommodation should fall on the system, not on the person. It insists that identity infrastructure should be designed to serve the full range of human naming practices, not just the ones that fit neatly into a 1980s-era database schema. And it demands that the communities most affected by these systems have a seat at the table when the systems are designed, not just when they fail.

What’s at Stake

The stakes are not abstract. When a voter is purged from the rolls because their hyphenated surname triggered a mismatch, they lose their franchise. When a family’s unemployment benefits are frozen because a diacritical mark triggered a fraud flag, they lose their income. When a tenant is rejected for housing because their name didn’t match across credit databases, they lose their home. These are not edge cases; they are the predictable consequences of designing identity infrastructure for a narrow cultural model of what a name looks like.

And the problem is growing. As more government services move online, and as identity verification becomes increasingly automated, the number of systems that can reject a name is multiplying. A person who navigates the voter registration system successfully may still be blocked by the benefits portal, the housing application platform, or the online court records system. Each of these systems has its own name field architecture, its own matching algorithm, its own assumptions about what a name should look like. The cumulative burden falls heaviest on the people who can least afford to navigate it.

Fixing this requires more than technical patches. It requires a shift in how we think about identity infrastructure—from a model that treats names as data to be processed to a model that treats names as expressions of identity and community that deserve respect and accommodation. It requires agencies to audit their systems for name-based exclusion, to publish the results, and to commit to remediation. It requires procurement rules that make name sovereignty a requirement, not an afterthought. And it requires the communities most affected to have real power in the design and governance of the systems that name them.

The Texas voter purge, the California EDD freeze, the ongoing exclusion of Native voters—these are not isolated incidents. They are symptoms of a deeper failure to design identity infrastructure that serves the full diversity of the public it claims to represent. Until we treat name sovereignty as a core design principle, the database will keep saying no.