What your site receives
A single boolean.true or false against the age threshold you asked for.
Your servers never receive a name, a date of birth, a document image, or a face. There is nothing
for you to store, encrypt, retain or delete, and nothing that can be taken from you in a breach.
This is the part that reduces your liability: you cannot expose data you never held.
What AnonAge sends to Sumsub
Identity verification is performed by Sumsub. The user goes to Sumsub’s own hosted page, so their documents travel from the user to Sumsub directly — not through us. What we send when starting a verification:
That is the entire payload. No name, no date of birth, no address, no country.
What AnonAge keeps
Four booleans and a timestamp. That is the whole record.
The consequence is a real cost, carried deliberately. A band cannot update itself, so somebody
verified at 17 has a record saying “not over 18” until they run a new check — which they pay for.
What makes that safe rather than merely cheaper is an asymmetry: a
true band never goes stale,
because people only get older. Only a false band can become wrong, so the failure mode is
always “an adult is asked to verify again”, never “a minor gets in”.
When documents are destroyed
By default, immediately. As soon as a verification returns a result — approved or rejected — AnonAge calls Sumsub’s reset endpoint, which destroys the documents and biometrics held for that person. It happens on the webhook that delivers the result, not on a schedule. A verification somebody abandons half-way never returns a result, so nothing on that path would ever ask for its documents to be deleted. A weekly sweep covers exactly that case, destroying the documents behind anything left unfinished for more than 48 hours. The delay is deliberate: it has to be longer than a slow but genuine verification, or we would be deleting documents while someone is still using them. After the reset, the only thing connecting AnonAge to Sumsub for that user is the applicant reference. There is nothing behind it. Rejected verifications are reset too. Someone who failed a check has even less reason to have their passport sitting with a third party.Deletion is triggered by us on the result, not by waiting for a retention period to expire. Under
Sumsub’s terms the retention period for a client’s data is defined by the client contractually
rather than by a dashboard toggle, so we do not rely on one: the reset call is the mechanism.
The user can opt out
Before a user is sent to Sumsub, they are shown this choice, ticked by default:Delete my Sumsub records — By default we ask Sumsub to destroy your documents as soon as we receive the result, leaving only a verification reference. Untick this only if you want your record kept at Sumsub for other reasons.If they untick it, their documents remain at Sumsub, we record that they chose this and when, and the choice is shown back to them on their account page. Documents persist at a third party only because the person asked for that — and we can evidence that they asked.
Read the code
The Sumsub integration is published as open source. It is deliberately small — a few hundred lines — so that someone technical can read all of it in one sitting:sumsubClient.ts— the only code that talks to Sumsub. Every request we send and every field we read back is in this one file, including the reset call described above.ageVerification.ts— the logic around the result, with no network calls: how a verified date of birth becomes a minimal age claim, and how inbound webhooks are authenticated.