One human, many accounts. One account, many humans. Both break your data.

Almost every system assumes an account is a person. It is not, in either direction, and the two failures are mirror images of the same missing thing: a durable, private binding between an account and a unique human. Solve the binding and both collapse.

Two meetings, same company, same Tuesday.

In the morning, the growth team presents. Forty one thousand new signups last month, a record, and the cost per acquisition is down. Everyone is pleased. In the afternoon, the fraud team presents to the same executives. Those forty one thousand signups contain, by their best estimate, around five thousand accounts belonging to people who already had one, plus an unknown number belonging to nobody at all. The retention curve everyone has been optimising against is measuring a population that does not exist in the shape the dashboard draws it.

Neither team is wrong. They are both counting accounts, because accounts are the only thing the system knows how to count.

Then, a week later, a different meeting. An auditor is reviewing a data export that moved forty thousand customer records to an external address. The log is complete and beautifully structured. It names the principal that performed the export: a shared operations account that eleven people have the password to, in three time zones, two of whom left the company this quarter. The log answers what happened, when, and to which records. It cannot answer the only question anyone in the room cares about.

These look like two different problems. They are filed with different vendors, budgeted by different teams, and written about in different publications. They are one problem seen from two ends.

What are the two failures, exactly?

One human, many accounts

Call it the 1:N failure. A single person operates multiple accounts on one platform, either casually or as a business. The casual end is a student making a second account for a second welcome bonus. The industrial end is an operator running hundreds of accounts to farm referral credits, evade a ban, inflate engagement, harvest financial aid, or complete paid surveys at volume.

What it breaks: deduplication, every per user metric you report, promo and referral economics, ban enforcement, Sybil resistance in anything that votes or rates, and exclusion lists. We have written about specific instances of this shape in one human, one review, survey panel fraud, and ghost students in the financial aid line. They read like separate problems in separate industries. They are the same arithmetic.

One account, many humans

Call it the N:1 failure. A single account is operated by several people. This gets far less attention than it deserves, partly because much of it is not fraud at all, which makes it easy to file under housekeeping and forget.

The mundane version is everywhere. A shared operations login because the tool charges per seat. A family streaming account. A small business bank login that the owner and the bookkeeper both use. A shared inbox for support. A social media account run by three people on a marketing team. A generic administrator credential kept in a password manager that eleven people can open.

The fraud version is the same mechanism with money attached: rented gig accounts where the person driving is not the person who passed the background check, resold subscriptions, and account farms operated by teams.

What it breaks: attribution, which means audit, which means every control that depends on knowing who did something. Insider activity hides perfectly inside a shared credential, not because anyone was clever but because the log has nowhere to put a name. Safety obligations fail, as we covered in who is actually driving. And every access review that says "this account needs these permissions" is answering a question about a role while pretending to answer one about a person.

Why they are the same problem

Here is the reframe that makes both tractable. Neither failure is really about accounts. Both are consequences of one absent fact: there is no durable, private link between an account and a specific human being.

Without that link, 1:N is undetectable because two accounts have nothing in common that a system can see, and N:1 is undetectable because two sessions have nothing distinguishing them. Add the link, and both questions become the same trivial comparison, asked at different times. Are these two accounts bound to the same human? Is the human on this session the human bound to this account?

The industry treats these as separate markets with separate vendors, which is why every platform buys two products and still cannot answer either question.

What does the 1:N failure actually cost?

Be careful with numbers here, because this is a field where confident figures circulate with unclear provenance. Widely cited industry estimates put annual United States losses to synthetic identity fraud in the tens of billions of dollars, and other frequently repeated figures put the share of digital account creations that are suspect in the mid single digit percentages. We are not going to assert either as fact, because the methodologies behind them are rarely published and the definitions vary enormously. What is defensible is the shape: this is a large, recurring, cross industry cost, and no platform has clean numbers on its own exposure precisely because measuring it requires the capability that is missing.

That last point deserves emphasis. You cannot measure duplicate accounts with a system that cannot detect duplicate accounts. Every published figure is a detector's catch rate, and every catch rate is a lower bound. Anyone quoting you a precise number for multi accounting is quoting you the part they found.

The case that is not about money

The most important application of one human, one account has nothing to do with fraud budgets, and it is the reason this problem deserves serious engineering attention rather than another risk score.

Self exclusion is a mechanism by which a person who has decided that gambling is harming them can ask to be blocked from gambling services. In Great Britain, the scheme run under the name GAMSTOP allows a person to self exclude from licensed online operators, and licensed operators are required to participate. Similar schemes exist in many jurisdictions. It is one of the few consumer protections in the entire digital economy that is genuinely about protecting people from a harm they have identified themselves.

It works by matching identity details. Which means it works exactly as well as identity matching works, which means a person in the grip of the thing they asked to be protected from can, with a different email address and a slight variation in how they enter their details, sometimes be somebody new.

The same structural gap sits under do not contact lists, court ordered platform bans, restraining orders applied to social products, and every exclusion a person or a court has asked a platform to honour. In each case a real human made or received a decision, and the platform can only apply it to a string.

If you want a single reason to care about the binding beyond unit economics, that is it. An exclusion list that a new email address defeats is a promise the industry is not keeping.

What does the N:1 failure actually cost?

Shared credentials are so normal that most organisations do not experience them as a risk at all. They experience them as how the work gets done, which is exactly why this is under discussed relative to its consequences.

The audit log that names a role

Every compliance framework in existence assumes individual accountability. SOC 2 asks who had access and what they did. Health and financial privacy regimes require that access to sensitive records be attributable to a person, because the entire enforcement model rests on someone being answerable for looking at a record they should not have. Change management asks who approved a production change.

When the answer is a shared account, all of those controls degrade to the same non answer: someone on the operations team, probably, during that shift, unless it was the contractor. Organisations then compensate with process, which is to say they write a policy saying shared accounts should not be used, and continue using them, because the tool charges per seat and the budget was set last year.

What makes this genuinely difficult, rather than merely neglected, is that the fix everyone proposes is individual accounts, and individual accounts are frequently blocked by things outside the security team's control: licensing costs, legacy systems with no multi user model, machinery and terminals in shared physical spaces, and the plain fact that a support rota needs continuity across people.

Where it turns into money and harm

Attach a payout or a safety obligation to a shared account and the same mechanism produces real damage. A rented delivery or rideshare account means the person at the door is not the person the platform vetted, which is a safety and insurance exposure rather than a data quality complaint. A shared administrator credential means an insider action is unattributable, and unattributable actions are the ones investigations stall on. A resold subscription is revenue leakage. A shared clinical or financial system login means an access review cannot tell an auditor who read a record.

In every case the log is complete, well formed, and useless for the only question that matters.

Why do identity resolution and fingerprinting fail?

The dominant approach to both failures is probabilistic matching. Collect signals, compare them across accounts and sessions, and cluster. The signals are the usual set: name and address normalisation, email and phone reputation, payment instrument, device and browser characteristics, network origin, behavioural timing.

This is a genuinely hard engineering discipline done by capable people, and it produces real value. It also has two failure modes that pull in opposite directions, and the industry talks about only one of them.

The false split, which everyone discusses

A false split is a duplicate you missed. The operator used a different device, a clean network, a fresh payment instrument, and entered their details slightly differently. Your cluster does not form. This is the failure the vendor pitch is about, and the response is always more signals.

The trouble is that the adversary controls every input. Device characteristics can be randomised, and browser vendors are actively reducing the entropy available for fingerprinting as a privacy measure, which means the signal degrades over time regardless of what any attacker does. The bot defence vendor hCaptcha has said publicly on its own site that traditional fingerprints are becoming useless, that browser makers are working to break them, and that attackers can easily emulate them. When a company that sells detection describes the substrate of detection that way, it is worth listening.

The false merge, which almost nobody discusses

A false merge is two real, different people combined into one record because their signals looked alike. This is not a missed catch. It is an active harm inflicted on a customer who did nothing.

Consider what it means concretely. Two people share a surname, a household address, and a laptop, which describes an enormous number of families, flatmates, and student houses. A matching system decides they are one person. Now: one person's ban applies to the other. One person's credit signal contaminates the other's file. One person's activity appears in the other's history. One person's exclusion decision, made about their own gambling or their own contact preferences, silently attaches to somebody who never asked for it. And when the affected person calls support to complain that their account has been restricted for something they did not do, the support agent sees a confident cluster and a risk score.

False merges are worse in exactly the populations that are already worst served: shared housing, extended families under one roof, communities where naming conventions produce many similar records, people who use library or shared computers, and anyone whose life does not produce a clean, isolated device and address signature. The system is least accurate about the people who can least afford to argue with it.

Vendors selling identity graphs rarely publish false merge rates. If you buy one, ask for that number specifically, and ask how a person appeals.

Why the deterministic answer is off the table

There is an obvious way to do this properly, and it is worth explaining why it is unavailable, because that constraint is the reason the problem has persisted rather than an oversight anyone can fix with more effort.

The deterministic answer is a government issued unique identifier. Collect it at signup, and 1:N becomes a primary key lookup. This is not available to most consumer platforms in most jurisdictions, for reasons that are mostly good ones. In some countries no such universal identifier exists. In some, using one for commercial identification is restricted or unlawful. Where identifiers do exist and are widely used, they concentrate risk: a database of them is a target, breach consequences are permanent because you cannot reissue a person, and the privacy posture of a private company holding national identifiers is one most regulators and most users would reject on sight.

So the industry is left with a real requirement, uniqueness, and a prohibition on the only mechanism that delivers it cleanly. The response has been probability. There is a third option.

What would an actual binding look like?

The requirement, stated precisely, is unusual and it is worth writing out because most designs fail it on the first or second clause.

A platform needs to determine whether two accounts belong to the same human, and whether the human on a session is the human who enrolled, without learning who that human is, without storing anything that identifies them, without a template that could be stolen and used elsewhere, and without creating a global identifier that follows the person across the internet.

That last clause is the one that most proposals fail, and it is not optional. A single stable identifier per human, usable by any platform, is a tracking identifier. It is the thing the advertising industry spent twenty years building and regulators spent ten years dismantling. Any design that produces one has traded a fraud problem for a surveillance problem, and we should say plainly that this would be a bad trade even when it is our own design being evaluated.

The one way key

The mechanism is a comparison of derived keys rather than a comparison of faces. A face match runs entirely on the person's device. Its output is not an image and not a reusable template, but a key derived through a one way function, scoped to a single platform context. The device sends the key. The platform stores the key. The platform never receives, and therefore can never lose, anything that describes a face.

The comparison is then trivial, which is the point. Duplicate detection is a set membership test.

# At signup. Everything above the line happens on the user's device.
# --------------------------------------------------------------
embedding   = on_device_face_match(camera, liveness_challenge)
context_key = hkdf(embedding, salt=PLATFORM_CONTEXT_ID)   # one way
# --------------------------------------------------------------
# Only context_key crosses the network.

def on_signup(context_key, account_id, store):
    if store.exists(context_key):
        return "duplicate", store.account_for(context_key)
    store.put(context_key, account_id)
    return "new", account_id

# Later, the mirror question, same primitive.
def on_sensitive_action(context_key, account_id, store):
    return store.account_for(context_key) == account_id

Two lines of logic answer both failures. on_signup answers 1:N. on_sensitive_action answers N:1, because a session that presents a different key than the one bound to the account is a different person, whether that is a rented gig account, a shared administrator credential, or a family member borrowing a login.

Note what the platform's database now contains: a column of opaque keys. There is no face to leak, no template to reuse, no document image sitting in object storage waiting to appear in a breach notification. We discussed why that storage posture matters so much in how to verify age without collecting an ID, and why the capture step itself is under attack in the camera is no longer evidence.

Why the key must be scoped per context

The salt in that derivation is doing the important work. Deriving with a platform specific context means the key one platform holds is mathematically unrelated to the key another platform holds for the same person. Two platforms comparing their databases learn nothing. There is no join.

The cost of this design is honest and should be stated: it gives uniqueness within a platform and deliberately not across platforms. A person banned from one service is not automatically identifiable at another, which is a feature for civil liberties and a limitation for fraud teams who would like a shared blocklist. Getting cross platform uniqueness without linkage requires cryptographic nullifiers, which is real research with real deployments in adjacent fields and is roadmap here rather than shipped. Anyone offering you cross platform uniqueness today without explaining how they avoid building a global identifier is offering you the global identifier.

How do the approaches compare?

The row that is usually missing from vendor comparisons is the last column. An approach can be accurate on average and still be the wrong choice if its errors land as unexplainable account restrictions on real customers.

Honest limits

Four of these are significant and one of them is structural.

• This says nothing about accounts that predate enrollment. A platform with ten million existing accounts that adopts this on Monday knows about the accounts enrolled from Monday. The back catalogue can only be covered by re-verifying at some natural moment, such as a sensitive action or a scheduled review, and that takes as long as it takes. There is no retroactive answer.
• A determined operator with many real humans defeats it. Uniqueness per human is exactly what it says. If an operation recruits five hundred real people and enrolls each one properly, it has five hundred legitimate accounts. This raises the unit cost of abuse by orders of magnitude, from free to the price of recruiting a person, and it does not make abuse impossible. Any vendor telling you otherwise is selling.
• Enrollment quality is everything, and liveness is the whole game. A naive design that accepts a photograph, a screen recording, or an injected video stream can be enrolled repeatedly by one person with a laptop. This is precisely the attack class we described in the injection attacks piece, and it means the liveness challenge at enrollment is not a detail, it is the control. A weak enrollment produces confident keys that mean nothing.
• Face matching has measurable error and demographic variation. This is the structural one. Independent evaluation programmes at NIST have documented for years that face recognition accuracy varies across demographic groups. Any deployment must publish its false match rate, must have a human appeal path staffed by people who can override the system, and must treat a duplicate flag as a signal for review rather than an automatic account closure. A platform that auto bans on a match will produce exactly the harms this post criticises in the false merge section, just with better mathematics.
• The legal status of a derived key is not settled everywhere. Biometric privacy statutes such as the Illinois Biometric Information Privacy Act, and the special category rules in the European General Data Protection Regulation, were written with templates and identifiers in mind, and the treatment of a one way derived key that never leaves the device as an image varies by jurisdiction and is developing. Get advice rather than assuming. This is not legal advice.

What to do this week

1. Measure your own 1:N exposure honestly by taking a sample of accounts and having a human review them for duplication, rather than trusting your existing detector's output. The gap between those two numbers is your real error rate.
2. Ask your identity resolution vendor for their false merge rate and for the appeal path a wrongly merged customer follows. If neither is documented, treat the cluster output as advisory rather than as a basis for enforcement.
3. Inventory your shared accounts, specifically the ones with production or customer data access, and record for each one why it is shared. Most will be licensing cost or legacy tooling, and knowing which is which turns a security complaint into a budget conversation.
4. Pick the three actions in your product where attribution actually matters and check whether a shared credential can perform them. Data export, permission change, and payout destination change are the usual answers.
5. Check whether your exclusion lists can be defeated by a new email address. If you operate anything with a self exclusion, do not contact, or ban obligation, this is the highest value thing on this list and it is not primarily a commercial question.
6. Write down whether you would accept a global cross platform identifier if a vendor offered one. Decide it as a policy before someone offers it in a deal, because the answer should not be made under commercial pressure.
7. If you evaluate a uniqueness check, ask three questions: what is stored, what does the person's device send, and what happens to a customer wrongly flagged. Those three answers tell you more than any accuracy claim.

Frequently asked questions

How can a platform tell if a new account belongs to a person who already has one, without storing biometrics? Run the face match on the person's own device and derive a one way key from the result, scoped to that platform. The device sends only the key. The platform stores only keys and compares them, so duplicate detection becomes a set membership test. No face, template or document is ever transmitted or retained, which means there is nothing to breach.

Is device fingerprinting still reliable for catching duplicate accounts? It is weakening for reasons unrelated to any single attacker. Browser vendors are deliberately reducing the entropy available, and the bot defence vendor hCaptcha has stated publicly that traditional fingerprints are becoming useless and that attackers can emulate them. It also has a high false merge rate, because a shared household device looks identical to one person with two accounts.

How do gig platforms detect account sharing today? Mostly periodic selfie checks and behavioural signals. The selfie check has a structural weakness: it verifies whoever is holding the phone at that moment, so if the registered account holder is present at check time, the check passes and someone else works the shift. A check bound to the action, at shift start or at a sensitive moment, closes that specific gap.

Does this create a global identity that follows me across the internet? No, and the design specifically prevents it. The key is derived with a platform specific salt, so the key one service holds is mathematically unrelated to the key another service holds for the same person. Two services comparing databases learn nothing. Cross platform uniqueness without linkage needs cryptographic nullifiers, which is future work rather than shipped.

What happens when the system wrongly says I already have an account? That is a false match, and every deployment must plan for it. The correct handling is that a duplicate flag routes to human review rather than to an automatic closure, that the platform publishes its false match rate, and that a person has a staffed appeal path. A system that auto bans on a match will harm real customers, disproportionately in shared housing and among groups where matching accuracy is measurably lower.

Is a one way derived key considered biometric data under privacy law? It depends on jurisdiction and the answer is still developing. Statutes such as the Illinois Biometric Information Privacy Act and the special category provisions of the European General Data Protection Regulation were drafted with stored templates and identifiers in mind. A key derived on device, from data that never leaves it, sits differently from a template in a vendor database, but you should get advice for your jurisdiction rather than assuming.

Why do multi accounting and account sharing count as one problem? Because both are consequences of a single absence: no durable, private link between an account and a specific human. Without the link, two accounts have nothing comparable and two sessions have nothing distinguishing. With it, both questions reduce to the same key comparison asked at different times, which is why buying two separate products still leaves both unanswered.

Sources

1. J. R. Douceur, The Sybil Attack, 2002, the foundational treatment of why identity multiplicity breaks distributed systems. microsoft.com/research
2. NIST Face Recognition Technology Evaluation, including demographic effects reporting. nist.gov
3. ISO/IEC 30107, biometric presentation attack detection. iso.org
4. Illinois Biometric Information Privacy Act, 740 ILCS 14. ilga.gov
5. Regulation (EU) 2016/679, General Data Protection Regulation, Article 9 on special categories of data. eur-lex.europa.eu
6. Great Britain Gambling Commission, on self exclusion requirements for licensed operators. gamblingcommission.gov.uk
7. GAMSTOP, the national online self exclusion scheme for Great Britain. gamstop.co.uk
8. hCaptcha, on the declining reliability of browser fingerprinting. hcaptcha.com
9. Semaphore, nullifier based signalling without linkage, as prior art for private uniqueness. semaphore.pse.dev
10. Privacy Pass architecture and issuance protocols, IETF. datatracker.ietf.org

The walk up demo runs the on device match and shows exactly what leaves the browser, which is the fastest way to see that the answer is a key and not a face. The developer documentation covers the enrollment and comparison calls.

You cannot measure duplicate accounts with a system that cannot detect duplicate accounts. Every published figure is a detector's catch rate, and every catch rate is a lower bound.