> ## Documentation Index > Fetch the complete documentation index at: https://docs.omnifence.ai/llms.txt > Use this file to discover all available pages before exploring further. # Privacy and security > What the Shared Registry stores, what it never stores, and who can see what The registry shares information about people with other companies, so it holds as little as it can and makes every action traceable. This page sets out exactly what it stores and who can see it. ## What the registry stores For each entry, the registry stores: * A 32-byte keyed hash of the user's normalised email (see [Hashing](/registry/how-it-works#hashing)). * The category of harm. * Which member reported it, and that member's case reference. * The entry status and its dates: created, last reported, expiry, and revocation. ## What the registry never stores * **No email addresses.** Members send a SHA-256 hash, never the email. The registry does not keep that hash either: it stores only an HMAC of it, computed with a secret key. * **No names, no other account data.** The registry accepts an email hash and nothing else about the user. * **No content.** A report never includes the images, text or other material behind a ban. The evidence stays with the member that made the ban. * **No trace of checks that do not match.** A check that matches nothing adds one to your daily check count. Nothing else is kept about the identifier. The database rejects any stored identifier that is not a 32-byte keyed hash. A plain SHA-256 digest or an email cannot be written to it by mistake. ## Why a keyed hash A plain SHA-256 of an email is not anonymous. Anyone with a list of email addresses can hash each one and look for a match, and large lists of addresses are easy to obtain. If the registry stored plain hashes, a copy of it would reveal which of those addresses belong to banned users. The registry stores an HMAC instead, computed with a secret key that only Omnifence holds. The key never leaves the registry service. Without it, the stored values do not match any hash of any email, so a copy of the registry reveals nothing. Omnifence holds the key, so Omnifence can compute the stored value for an email it is given. Omnifence does this only to answer a request from the person named, or to handle a dispute. Every such lookup is recorded in an audit log with its purpose. ## Who can see what | Who | Can see | Cannot see | | - | - | - | | The reporting member | Its own entries, with status, dates and its own case reference. | Entries from other members. | | A member that checks | For a matching identifier: each category, the number of members that reported it, and the first and last report dates. | Which member reported it, entry IDs, case references. | | Omnifence | Every entry and its reporting member, when handling a request from the person named or a dispute. | Emails, unless the person or a member gives one to Omnifence. | | A copy of the registry data | Keyed hashes, categories and dates. | Emails, or which emails the hashes belong to. | A member cannot read, change or revoke another member's entries. The registry enforces this in the database itself, not only in the API. ## Retention Every entry has a fixed retention period that depends on its category. The period restarts when the member reports the user again. | Category | Retention | | - | - | | `payment_fraud` | 2 years | | `prohibited_content` | 3 years | | `ban_evasion` | 1 year | When the retention period ends, the entry stops matching. It is deleted 30 days later. A revoked entry is deleted 30 days after it is revoked. Deletion removes the entry and every record linked to it. ## Audit trail The registry records every report, revocation, dispute, matching check and Omnifence lookup, with who performed it and when. The audit trail never contains an email or a hash. When a check matches, Omnifence also records that your account matched that entry. That record is deleted with the entry. ## Rights of the people named A person can ask Omnifence what the registry holds about their email, and can dispute an entry. While a dispute is open, the entry does not match. See [Disputes](/registry/disputes). ## Legal responsibilities Each member is responsible for its own use of the registry under the data protection law that applies to it. In particular, you must tell your users that you share and check banned-user data through the registry, in your privacy notice and terms. The registry is designed around narrow categories of serious harm (fraud and prohibited content) because those are the purposes that support sharing this kind of information. Take your own legal advice on your obligations. The registry does not replace any legal duty to report illegal content or other crime to the authorities. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.