Who is responsible for your data here
XEX plays two different roles, and which one applies decides who you go to.
| Data | XEX's role | Who decides why it is processed |
|---|---|---|
| This website | Controller | XEX — visitors to xex.to, including the consent decision and the country decision at the edge. |
| Operator accounts | Controller | XEX — the people an operator gives console access to: sign-in, roles, audit and billing. |
| Members inside a workspace | Processor | The operator running that programme. XEX processes on its instructions under the data processing addendum. |
| Platform identity index | Controller | XEX — a non-reversible identity handle and the email it was verified against, so one person is not asked to verify twice across workspaces. |
If you are a member of a programme and want data changed or deleted, your first route is the operator of that programme — they decide. XEX will pass a request on to them and will help them answer it. See Data Processing Addendum.
The controller for the data XEX decides about is [[ To be supplied — XEX legal entity name ]] of [[ To be supplied — registered address ]]. Data-protection enquiries go to [[ To be supplied — privacy contact address ]].
Three questions here cannot be answered from the codebase and are open: whether an Article 27 representative is required in the EU or UK given the geographic policy; whether a data protection officer must be appointed; and whether the combination of a take rate on programme volume, geographic and eligibility decisioning, and supplied marketing templates makes XEX a joint controller with an operator rather than its processor. No name or appointment is asserted here, in either direction, until that is settled.
What data is handled
Grouped by who you are. Nothing in this list is aspirational — each row names data the platform actually stores.
| Category | What it is | Where it comes from |
|---|---|---|
| visitor | IP address, and the country derived from it; the request path and whether the request was allowed, observed or blocked; the rule that matched. | Automatically, from the request. The country decision is made from a local address-range table in our own database rather than a third-party lookup. |
| consent | Your cookie decision, and which purposes you accepted. | You, when you press a button on the consent banner. Stored in your own browser. |
| operator | Email, display name, account status, whether multi-factor is enabled, a password hash where a password is used, passkey credentials, the workspaces and roles you hold, session records. | You, or the operator who invited you. |
| member | An identity reference from the operator's own systems, an account reference, display name, email, verification status, country, the last IP seen, enrolment date, your position in the programme's genealogy, your purchases, ledger entries, claims, disputes, and your acceptance of the programme's terms with the time and IP of that acceptance. | The operator, and you, through the programme's own flows. |
| verification | The provider used, the provider's session reference, the decision (pending, approved, declined, in review), a short reason, and a non-reversible identity handle. | The identity-verification provider. Identity documents are never sent to or stored by XEX. |
| security | An append-only audit record of operator actions: who, in which workspace, what action, on what subject, when. | Automatically, from console actions. |
| marketing | Attribution touches (campaign source, medium, campaign, referrer, landing path, first and last) and per-purpose marketing consent flags, held per programme. | Your interactions with a programme's own links, on that operator's configuration. |
| payment | Payment intents and their events: amount, currency, method, provider reference, status. Card numbers and crypto private keys are never received or stored by XEX. | The payment provider on the operator's own account. |
No identity documents. Verification returns a decision and a handle that cannot be reversed into a document or a name. That is the whole record.
No card data and no keys. Payments run on the operator’s own provider accounts. XEX is not in the card-data path and holds no private keys for anyone.
Why, and on what legal basis
| Purpose | Data used | Basis (UK/EU GDPR Art. 6) |
|---|---|---|
| run the website | visitor | Legitimate interests — operating and securing a website we publish. |
| decide access by country | visitor | Legal obligation, and legitimate interests in not offering a service where we are not permitted to. See the sanctions policy. |
| provide the platform | operator, member | Contract with the operator; for members, the operator's own basis under its terms, on which XEX acts as processor. |
| authenticate and protect accounts | operator, member, security | Contract, and legitimate interests in preventing unauthorised access. |
| prevent fraud and abuse | visitor, member, security | Legitimate interests in preventing duplicate identities, sybil enrolment and payment abuse. |
| keep an audit record | security | Legal obligation where records must be kept, and legitimate interests in an accountable money path. |
| verify identity | verification | The operator's legal obligation, for which XEX acts as processor; and legitimate interests in one-person-one-position integrity. |
| bill an operator | operator, payment | Contract, and legal obligation for tax and accounting records. |
| analytics and advertising | consent, marketing | Consent — and nothing in this category is processed unless you give it. |
Where we rely on legitimate interests we have considered whether they are overridden by your rights, and you may object — see Your rights below.
Automated decisions
Two decisions here are made automatically, and you should know about both.
The country gate
Before you are known to us at all, your IP address is resolved to a country from a local address-range table and checked against a published country policy. The result is one of three: allowed, observed (recorded but not enforced), or blocked. A blocked request receives HTTP 451 and an explanation rather than a broken page. The countries, the reason code recorded against each, and the way the policy is enabled are published in Prohibited Jurisdictions and Sanctions Policy.
This decision is made on an IP address, not on a profile: it does not analyse your behaviour, and it draws no inference about you. An operator can grant a recorded, time-limited exception for an individual member from a specific network prefix, with a written reason.
Duplicate identity
Where identity verification is in use, one approved person may hold one position in a workspace. A second position that resolves to the same identity handle is refused by the database. The purpose is to stop one person earning on their own downline through several accounts.
In both cases you may ask for a human review by writing to [[ To be supplied — privacy contact address ]], and where the decision is a programme’s rather than the platform’s, to the operator.
Who else sees it
Data is shared with the service providers listed in Sub-processors, and only for what that page says each one does. It is also shared:
- with the operator of a programme you are a member of — they are the controller of your membership data;
- with professional advisers, auditors and insurers where necessary;
- with a regulator, court or law-enforcement body where we are legally required to, and where we are permitted to tell you, we will; and
- with an acquirer, in a reorganisation or sale, subject to equivalent protection.
Data is not sold, and is not shared with an advertising network except through a tag you have consented to. The consent gate is enforced server-side for the conversion forwarding an operator may configure: nothing is forwarded for a member who has not given the matching consent.
Where it is processed
The platform runs on cloud infrastructure in [[ To be supplied — hosting region ]], and the providers in Sub-processors may process data in other countries.
The transfer mechanism for each recipient — standard contractual clauses, an adequacy decision, or a UK addendum — depends on the entity, the hosting region and the sub-processor contracts actually in place. None is asserted here, because asserting one that does not exist would be worse than the gap.
How long it is kept
This section is written honestly rather than aspirationally, because a retention schedule nothing enforces is a statement that will be tested and found untrue.
| Data | What actually happens today | Target |
|---|---|---|
| cached country verdicts | Cleared whenever the country policy changes, and re-derived on next use. | No target needed — the cache is derived data. |
| blocked/observed request records | Retained. Deduplicated into time buckets with a hit count rather than one row per request. | [[ To be supplied — retention period ]] |
| audit log | Append-only and enforced by a database trigger. It cannot be edited or deleted by the application, by an operator, or by us. | [[ To be supplied — retention period ]] |
| ledger, purchases and claims | Append-only. Corrections are additional entries; nothing is rewritten. | [[ To be supplied — retention period ]] |
| member and operator accounts | Retained while the workspace exists. Deletion is performed on request, subject to the constraints below. | [[ To be supplied — retention period ]] |
| verification decisions | Retained as a decision plus a handle. No documents exist to expire. | [[ To be supplied — retention period ]] |
There is no automated retention-expiry job in the platform today. Deletion is a manual, recorded action. Stating that plainly is the point of this table.
Your rights
Subject to the law that applies to you, you may ask for access to your data, for it to be corrected, for it to be erased, for processing to be restricted, for a copy in a portable form, and you may object to processing based on legitimate interests. Where processing is based on consent you may withdraw it at any time, and withdrawing it does not affect what happened before.
The ledger and the audit log are append-only by design — that is what makes a compensation figure defensible and an operator’s action attributable. An erasure request is met by removing or redacting identifiers (a member record carries a redaction marker for exactly this), not by deleting financial or audit entries, which we retain where retention is required or where the record is needed to establish or defend a legal claim. We will tell you which applies to your request rather than answering it silently.
To exercise a right, write to [[ To be supplied — privacy contact address ]]. If you are a member of a programme, we will identify the operator responsible and pass the request to them, and we will tell you that we have. You may also complain to a supervisory authority; the lead authority for XEX is [[ To be supplied — supervisory authority ]].
How it is protected
The measures below are structural rather than procedural — they are properties of the code and the database, not promises about behaviour:
- Every query in the data layer takes a workspace. There is no call site that can omit it, so cross-tenant reads are not something policy prevents — they are something the code cannot express.
- The audit log is append-only, enforced by a database trigger that raises on any update or delete.
- Credentials an operator stores for its own payment rails are sealed, and the rail configuration refuses to store a credential belonging to the platform.
- API keys and webhook secrets are per workspace and carry a key identifier, so a key can be rotated with an overlap rather than an outage.
- Operator sign-in supports passkeys and time-based one-time codes, and console roles separate duties across six roles; sections a role may not see render an access notice, never data.
- Destination URLs an operator configures are checked against server-side request forgery and egress rules before anything is sent to them.
What is not claimed: no SOC 2 report, no third-party penetration test, no certification, and no availability commitment. Those absences are stated here and on the compliance and security pages rather than being left for someone to discover.
Children
The platform is not for anyone under 18, and programmes must not enrol them. We do not knowingly process children’s data; where we learn that we have, we delete it and tell the operator concerned. Report a suspected under-age account to [[ To be supplied — privacy contact address ]].
Changes to this policy
When this policy changes, the replacement is published here. Material changes affecting operators carry the notice period in Platform Terms. There is no effective date on this draft because it has not been approved; once it has, each published version will be identifiable, and superseded versions will remain available on request. In the meantime, the specific gaps are the ones marked To be supplied above.