Verify users. Store nothing.

July 17, 2026

Every app that bans users eventually hits the same wall: the ban doesn't stick. Someone gets removed, and they're back an hour later with a new email and a fresh account. Same person, clean slate.

The obvious fix is to tie each account to a verified identity (a government ID, a face) so account #2 can't quietly become account #3. But that fix creates a second problem that's usually worse than the first: to check whether a new signup matches a banned person, you have to store everyone's identity. Now you're holding a database of government IDs and biometrics, exactly the thing attackers want and regulators scrutinize. Dating apps, marketplaces, and communities all run into this the moment they take bans seriously.

So platforms are stuck choosing between two bad options: bans that don't hold, or a honeypot of personal data. NoNo Ninja is our answer to that choice. Bans that survive new accounts, without you ever storing the identities they're matched against.

What actually happens

A user signs up on your platform and verifies once, through a standard identity provider: they present a government ID and a selfie, and the provider confirms they're a real, unique person. Neither you nor we ever touch the ID or the selfie. The provider holds those just long enough to verify, and they're automatically destroyed 30 days after the check. Past that window, the document doesn't exist anywhere in the pipeline.

What you get back, within seconds, is a signed webhook with the result. It tells you three things: the verification passed or failed, the claims that were proven (over 18, over 21, US resident), and whether this person has been here before. That last one is the point. If a new signup matches someone you banned, the webhook arrives with a flag on it, strong or weak depending on how the match was made, and your system decides what to do: block the signup, route it to review, whatever your policy is.

What lands in your database is a pass/fail record with a timestamp (which is what a compliance audit actually wants to see) and an opaque token. No ID, no face, no name, no birthdate. There is nothing to breach, nothing to subpoena, and nothing for a regulator to ask why you're still holding.

This is live in production today. You can run a real verification yourself and watch the system flag you as a returning verifier at nononinja.com/demo, including the part most systems can't do: it catches the return even if you come back with a different government document than the one you first used.

How the matching works

From the verified attributes we derive two values: an HMAC-SHA256 over each of two normalized identity anchors (document number plus date of birth, and name plus date of birth), keyed with a per-business secret, with the business ID folded into the hashed input. In practice that means the same person hashes to a different value for every platform. There's no shared identifier and no way to correlate a user across businesses; two platforms hashing the same human get unrelated outputs, and neither can derive the other's.

A ban is then just a hash on a list. Someone new verifies, we compute their hashes, we check them against your banned ones. A match means "this is someone you removed," without you ever learning, or storing, who they are. The two anchors carry different weight, deliberately: a document-number match is treated as a match, while a name-and-birthdate match is a flag for review, never an auto-reject, because names repeat and birthdays collide. (The same verification can separately prove claims like "over 18" without disclosing the data behind them. Same principle throughout: prove what's needed, keep what you don't.)

Where the limits are

None of this is magic, and we'd rather tell you where the ceiling is than pretend there isn't one. A hash-based ban is exactly as strong as the stability of what you're hashing, and identity data is less stable than it looks: names transliterate differently across documents, change with marriage, arrive with different capitalization from different runs. Our normalization is deliberately minimal, because every rule that catches a variant is a rule that might merge two genuinely different people, and we'd rather miss a rematch than manufacture a false one.

The sharpest gap we've closed so far is the second-document problem, and we'll be precise about it because we found it ourselves the week this post first went up. Most adults own two government IDs, and as originally shipped, a passport instead of a driver's license produced a fresh document hash and a clean slate. That's since been closed: every verification now computes both anchors and checks both, so a second document misses on the document hash and hits on the person hash, which raises the review flag. Fully evading a ban now requires a government document with a different name or birthdate, meaning a legal name change or fraud upstream of the identity provider.

One more piece of honesty, about the cryptography. The ZK proofs in the pipeline prove statements like "over 18" without revealing the date of birth behind them. That part is trustless math. What the math alone doesn't prove is that the attributes belong to the human who sat for the verification; that binding rests on the identity provider (Persona, in our case) having matched the selfie to the ID and confirmed liveness. Cryptographic guarantees on top of an attested verification, not a system with no trusted parties. Anyone who tells you their ID-verification stack is fully trustless is either wrong about what "trustless" means or hoping you won't ask where the ID check happens.

Where we are, and an invitation

NoNo Ninja today is a working API, not a finished product. Verification, per-business hashing, ban matching, webhooks, and attribute proofs all run live in production. The security posture is where we want it: no stored IDs, no stored biometrics, database off the public internet, and the whole surface recently put through an outside-in audit. What it isn't yet is battle-tested against messy identity data at scale.

That's the part we can't build alone. Normalization rules, weak-match policies, the right review workflow when a flag fires: these get shaped by real signups from real platforms. So we're looking for a small number of design partners: dating apps, marketplaces, communities, and age-restricted retailers that take bans and compliance seriously and don't want to become a honeypot to do it. You'd get the API, direct access to us, and real influence over how the hard parts get resolved. We'd get the thing we actually need – contact with reality.

If that's you, we'd like to talk: james@nononinja.org