People who report a gambling dispute are often already exposed: mid-way through a verification process, holding a balance they cannot reach, or still logged in to the operator they are complaining about. What we collect, and who can see it, is designed around that.
01Collection
The complete list. Three fields and one confirmation are required — the operator, the category, your account of what happened, and the tick; everything else is genuinely optional, and a report with only those is a valid report we will act on.
What we do not ask for
No account name, no player ID, no date of birth, no address, no card or bank details, no copy of your identity document. If a document you upload happens to contain them, it is flagged as containing identity material and handled under the narrower access rules below — but we never ask you to send one.
What you get back
A reference, shown once. The database holds a one-way hash of it and not the reference itself, so it is a key you hold and we cannot reconstruct — you can check the status of your case with it, and nobody needs an account. Our own reviewers see a case number instead, because there is no reference for them to see.
Check a reference02At rest
Three different techniques, used for three different reasons. None of them is a substitute for access control, which is enforced separately.
The email address you choose to give is encrypted with authenticated symmetric encryption before it is written to the database, and decrypted only when a permitted role opens the record. A leaked copy of the database file does not yield a list of reporters. Reviewers who need context without needing the address see a masked hint instead.
The reference column was removed from the reports table: what is stored is a one-way hash of the reference, and the reference is not stored anywhere. So the lookup runs one way. Quote your reference to us and it can be confirmed against the hash; nobody on our side can go the other way and derive it from a record, which is why our reviewers work from a case number instead. Submission IP addresses are hashed the moment they arrive and the address itself is discarded — enough to stop automated abuse, not enough to locate anybody.
Attachments are written outside the web root under opaque names, so there is no guessable URL to any of them. Each file is checked against its declared type by inspecting its actual leading bytes, and anything containing identity material is marked as such so it can be handled more narrowly.
Private reports live in a different table from public case files, and nothing in the report table is served on a public route. A case file is a separate record written deliberately by a reviewer, holding only the fields that reviewer copied across after redaction.
03Access
Access is granted by role, and each role is a fixed set of named permissions rather than a level of seniority. The matrix below is generated from the permission set the platform actually enforces — it is not a description of it.
| Role | Aggregate metadata | Report body | Reporter contact details | Uploaded evidence |
|---|---|---|---|---|
| Administrator | Permitted | Permitted | Permitted | Permitted |
| Editor | Permitted | Permitted | No access | No access |
| Investigator | Permitted | Permitted | No access | No access |
| Researcher | Permitted | No access | No access | No access |
| Case reviewer | Permitted | Permitted | Permitted | Permitted |
The consequence worth spelling out: investigators and researchers — the people who write most of what you read — cannot see who sent a report or open what they uploaded. Reporter identity is reachable by two roles only, and every access to a report is written to an audit trail that the person taking the action cannot edit.
04Retention
Retention is tied to the purpose the data was given for. When the purpose ends, so does the retention.
Consent works on the exact version, not on the idea of publication. Before a case file drawn from your report can be published, you are shown that precise text and exhibit list through your reference and asked to approve it; you can withdraw that approval at any time before it goes out. Your approval stays attached to the version you were shown. If that text or its exhibits are edited afterwards, what you approved is no longer what the record says, so your approval does not carry across — the edited version cannot be published until a fresh request has been put to you and you have approved that one too. There is no second basis: without your approval of the exact version, nothing drawn from your report is published at all.
Your controls
Sharing outside GambleLABS
A report is shared with a regulator or dispute-resolution scheme only where you have specifically consented to that. We do not sell, rent, licence or trade report data, and we do not pass it to operators — including the operator your report concerns.
05Publication
Nothing you send becomes public by default. These categories are not publishable at all — not with consent, not in redacted form, not as an illustrative detail.
A report becomes public only as a case file: a separate record, written by a reviewer, containing a redacted narrative and a redaction note that tells readers what was removed. The reviewer copies across what is necessary to make the case intelligible — the category, the jurisdiction, an amount band, the outcome — and nothing else.
Your approval is asked for at that point — after the redacted version exists and against that version — never assumed from the fact that you contacted us or from a box ticked when you filed. A case file records the basis it was published on, and one published on your approval is unpublished if you withdraw it.
We also watch for identification by elimination. A category, a country, a date and an amount can identify one person as effectively as a name, so the redaction test is whether the operator could work out who you are — not whether your name appears.
06Discoverability
The platform runs one unified search index across every public record type. Reports have no route into it, and this is enforced in the code that writes the index rather than by filtering results afterwards.
The invariant
A record may enter the search index only if it is already public on its own route. Player reports, uploaded attachments, evidence records, internal analyses and audit events have no indexer at all — not a disabled one, not a filtered one.
Drafts, in-review records and approved-but-unpublished work are likewise absent. Approved means cleared to publish, not published, and a search box that returns a record nobody has published is a disclosure with extra steps.
The only public expression of a report is a redacted case file, and it is the case file — not the report — that is indexed. Searching this platform for your own name, your account or your operator correspondence will not find your report, because it is not there to find.
07Everything else
Stated because the sections above are about reports, and this document is the whole account. There is no third-party analytics beacon anywhere on this platform and no advertising or profiling tracker of any kind; what exists is a small number of first-party rows this platform writes for itself.
What is refused
The homepage challenge. The Network Resolver issues a fresh board on every page load, and the board has a promotional reward attached to it — so it has to be able to tell one visitor’s challenge from another’s without knowing who anybody is. A signed anonymous cookie carries a random token; the database stores a keyed hash of it beside the board that was issued, the moves that were played, how long it took, and a counted event for each of viewed, started and claim pressed. No address, no fingerprint and nothing about you: the hash is useless outside this deployment’s key, and it exists so that one solved board yields one reward code.
Rate limiting. The challenge endpoint and the event endpoint each count requests per time window against a hash of the requesting address. The address itself is discarded on arrival, as it is on the report form. This is what stops a script minting reward codes; it is not enough to locate anybody.
Your own account, if you create one. A signed-in member’s searches, follows, bookmarks and notification settings are stored against their member id — so that a reading list is a reading list. Every one of them is visible to you in your workspace and can be cleared by you; your searches and your reading history are two separate lists on your reading history page, each with its own delete. An anonymous search writes no row at all: there is nobody to attribute it to, and attributing it to an address would create exactly the record this design exists to avoid.
Access and export logs. Every staff access to a report, and every member export, writes an audit row carrying the action, the outcome, the actor and a hash of the requesting address. That trail is the mechanism behind the access guarantees in section 03: it cannot be edited by the person who triggered it, and it is what makes those guarantees auditable rather than merely stated.
Reading your own export log. There is no screen in your workspace that shows it — we are saying so rather than implying one. The rows exist and are retained; if you want the list of exports recorded against your account, ask through the submission form and we will produce it. The searches, follows, bookmarks, reading history and notification settings described above are a different matter: those you can see and delete yourself, today, from your workspace.
