Blog
August 29, 2026
-
6 min read

First Name: Unknown

DBC1 Team

Product & platform

Writes about enterprise identity, card infrastructure, and the operational details that usually get skipped.

Fun fact: there are people in the United States whose legal first name is FNU.

It isn't a name. It's an acronym — First Name Unknown — inserted by data-entry systems that demand two name fields when a passport supplies only one. Someone arrives from Indonesia, or Afghanistan, or a Tamil-speaking part of India, carrying a single legal name. The form has a slot for a given name and a slot for a surname. The real name goes in the surname field, because that's the one systems treat as primary, and the given-name field gets a placeholder.

The placeholder was meant to be temporary. In practice it propagates: visa, then I-94, then the Social Security record, then the driver's licence, then the employer's HR system, then the badge, then the business card. Correcting it isn't a single step — each record feeds the next, so they have to be fixed in order — and because the immigration service has no authority to rename anyone, the sequence often starts in a state court.

Somewhere at the origin of that chain is a database schema. Someone chose two fields. That choice became part of a stranger's legal identity.

I want to make an argument that sounds overstated and isn't: the name fields in your HR system are a policy decision about whose identity your organisation can represent correctly. If you operate across forty countries, that decision has already been made — probably by a vendor, probably by default, and probably wrong for a meaningful share of your people.

Programmers have known a version of this since Patrick McKenzie's Falsehoods Programmers Believe About Names in 2010. What follows is less about the falsehoods themselves and more about what they cost an organisation that has to sort, address, greet, and print the people in its directory.

The surname is not a family name

In Iceland, most people don't have one. Names are patronymic: Jón, son of Ólafur, is Jón Ólafsson. His sister is Ólafsdóttir. Their father, son of a Jón, is Ólafur Jónsson. Three members of one household, three different "last names," none of them shared, none of them inherited. A fourth is now possible — the 2019 Gender Autonomy Act introduced the suffix -bur, "child of," for people registered under a non-binary gender marker.

Icelandic phone directories sort by given name, because sorting by patronymic would be meaningless — it would group everyone whose father happened to be called Jón.

The same structure appears in Ethiopia and Eritrea, where a person's second name is the father's given name and the third is the grandfather's. It appeared across the Arabic-speaking world long before European surnames existed, in a system with more moving parts than most schemas contemplate: the given name, the nasab chain of descent, the kunya (father or mother of so-and-so), the laqab or epithet, and the nisba marking place, tribe, or profession.

None of this is exotic edge-casing. It's the naming system of hundreds of millions of people, and it does not survive contact with a field labelled "family name."

The surname is not singular

Spanish-speaking countries use two. Traditionally the paternal surname comes first and the maternal second — though Spain has permitted parents to choose the order since 1999, and a later reform removed the paternal default entirely, leaving the registrar to decide where parents don't agree.

The first surname is the primary one. This is the detail Anglophone systems get wrong: presented with María García Ruiz, they file her under Ruiz, or drop García as a middle name, or truncate to "María Ruiz." All three are wrong, and the third is a different person. Portuguese practice inverts the order and permits up to four.

The surname is not constant within a family

In Polish, Russian, Czech, and elsewhere in the Slavic languages, surnames inflect for gender: Nowak and Nowak, but Kowalski and Kowalska, Ivanov and Ivanova, Novák and Nováková. A husband and wife share a surname in the sense that matters socially and none of the senses that matter to a string comparison.

This breaks a specific assumption more often than people expect — the assumption that a surname is a fact about a family that can be stored once and applied to its members.

The order is not given-then-family

Hungary puts the family name first, in Europe, in the Latin alphabet, with no visual cue. So does China, Korea, Vietnam, and Japan — and in Japan the convention for Latin-script rendering recently changed. A government directive issued in October 2019 and effective from January 2020 flipped Japanese names in official English-language documents back to family-name-first, reversing a practice adopted roughly 150 years earlier to look more Western. The directive also recommended capitalising the family name — ABE Shinzo — precisely because order alone is ambiguous.

Adoption has been uneven. Which means that today, a Japanese name in Latin script may be in either order, and the only reliable way to know is to ask the person.

Sorting is not display

In the Netherlands, the particles in surnames — van, de, van der, ten — are ignored when alphabetising. Jan van der Heide files under H. Dutch databases typically store the particle in its own field for exactly this reason. Cross into Belgium and the convention inverts: the particle is part of the surname, kept in its original capitalisation, and sorted with it. Van Der Velde files under V.

So the same name, spelled identically, sorts differently depending on which country's directory you're in. And the Dutch rule has a further wrinkle: the particle is lowercase after a given name (Jan de Vries) but capitalised without one (meneer De Vries). Any system that title-cases names on write has already destroyed this.

Address form is not derivable from the name

In Russian, respectful address is the given name plus the patronymic — Ivan Ivanovich — not a title plus surname. "Mr Petrov" is grammatically fine and socially foreign.

In Thailand, almost everyone has a chue len, a nickname given at birth, and it's what colleagues actually use, at work, daily. Thai surnames are a recent import: the Surname Act of 1913 required them for the first time, and required each one to be unique to a single family, which is why they run so long — early registrants took the short combinations and everyone since has had to build something unclaimed. Two Thais with the same surname are almost certainly related. And in formal Thai usage, people are still referred to by given name, not surname.

In German-speaking Europe, academic titles are part of professional identity in a way that isn't decorative. Elsewhere, a title can carry legal weight: prokurent in Poland, representative director in Japan. Somebody handed a card that says "Director" may reasonably infer authority to bind that the company never meant to grant.

What to actually do

The instinct on reading all this is to add fields. That's the wrong lesson. More fields means more ways to be wrong, and it pushes the modelling problem onto whoever fills the form. The better direction is to store less structure and more authority.

Treat the display name as the primary field, not a computed one. Don't assemble it from parts at render time. Store the string the person's name actually is, and let structured components be optional metadata around it.

Let the person edit it. The employee is the only authority on their own name. This single control resolves order, particles, mononyms, diacritics, nicknames, and every case nobody anticipated — and it costs one text input.

Keep the sort key separate from the display name. They answer different questions and follow different rules per locale. Conflating them is how van der Heide ends up in the wrong section of the directory.

Don't validate names. No minimum word count, no regex, no Latin-only. Names contain one word, five words, apostrophes, hyphens, spaces, diacritics, and scripts your font may not cover.

Never auto-capitalise. McDonald, d'Angelo, van der Berg, ter Horst — title-casing corrupts all of them. And uppercasing is locale-dependent: Turkish has dotted and dotless i, so a naive toUpperCase mangles Turkish names in a way Turkish readers notice immediately.

Don't infer gender from a name, and don't derive one family member's surname from another's.

Treat transliteration as a proposal, not a result. A name rendered into katakana, or into Chinese characters, is a different name — for Chinese in particular, character selection is a choice with meaning, not a phonetic mapping. Generate a candidate if it helps; never publish it without the person confirming it. The same discipline applies to job titles, which should be stored per locale as human-written strings and never machine-translated.

Assume names change. Marriage, divorce, transition, naturalisation, correction of an error someone else made a decade ago.

Most of this is recoverable on a screen. A misspelled name renders again on the next page load, and the cost of getting it wrong is an apology.

Printing removes that. A card is a decision rendered permanent at scale — a thousand people, a thousand small statements about how the organisation understands who they are. If the model behind it thinks every human has exactly two names in exactly one order, some of those statements are wrong, and they're wrong in boxes, on a shelf, for the next two years.

Which is a good reason to look at the schema before the print run.