Identifiers and normalisation
Normalisation before hashing is what makes a hit possible, so it is fixed in the specification and every member runs the same rules.
| Identifier | Normalisation before hashing | Why it is in |
|---|---|---|
| Lower-case; strip dots and plus-tags in the local part for providers that ignore them; strip whitespace | The cheapest identifier, and the first thing every operator holds | |
| Phone | E.164 digits only, country code included | Verified phones are reused far more than emails |
| Payment instrument | The processor's network token or card fingerprint, never the card number; bank account hash where bank transfers are used | A ring rotates emails for free and cards at a cost |
| Device | The member's own device id as issued, prefixed with the member id | Catches the lazy half of multi-accounting |
| Government identity | Document type, issuing region and document number, normalised to upper-case letters and digits | The only identifier a person cannot change |
| Name and date of birth | Last name upper-cased without punctuation, plus date of birth as YYYYMMDD | Weak alone; useful as a second factor on a hit |
Hashing
SHA-256 over the normalised value with a consortium-wide secret salt, held by the neutral operator and rotated yearly with a re-hash of the store.
A member-specific salt would make the same person a different hash at each member, which defeats the point. A public salt would let anyone build a rainbow table of phone numbers, which is cheap. The salt is the one secret in the system, and the reason the operator must be neutral.
What a query returns
Per hit: the reason codes, the filing month, the expiry, and an opaque filing-member reference the neutral operator can resolve for a dispute. It never returns which member filed. Queries are logged and rate-limited per member.
The record lifecycle
A record lives from a member's own account closure to its expiry or a successful dispute, and a hit never decides anything by itself.
- File. A member closes an account for a listed code, then files the hashes with the code, a filing month and an internal case reference it keeps. Filing is a deliberate act by a named person, never an automatic side effect of a ban.
- Query. Another member queries at sign-up, first deposit, first withdrawal, and on any internal fraud finding. A hit comes back as codes and dates only.
- Decide. The querying member applies its own written policy to the hit: refuse, hold for review, require stronger verification, or do nothing for a given code. Members do not share or align these policies.
- Notify. Where a member acts on a hit, it tells the person that a shared fraud record contributed and how to dispute it.
- Dispute. The person disputes through the neutral operator, which routes it to the filing member without naming it. The filing member has 30 days to confirm the evidence standard was met or withdraw. No response withdraws the record.
- Expire. Each code carries a default expiry. An expired record is deleted, not archived. A member may withdraw its own record at any time.
Two things are deliberately absent. There is no record about a person who was merely suspected, and there is no way to see another member's evidence. The exchange brokers a yes-or-no and a dispute, nothing more.