Privacy policy

Parity is business-to-business infrastructure. It sits between an OPERATOR — the platform that holds the customer relationship — and a VENUE that lists and settles event contracts. Three parties, three sets of responsibilities, and almost every question about this service is answered by working out which one owns the thing being asked about.

THE OPERATOR owns the end customer: the account and its credentials, KYC — identity and age verification — the customer cash ledger, deposits and withdrawals, bonuses, deposit and loss limits, time-outs and self-exclusion, and first-line customer support. Parity holds none of those and cannot act on any of them.

PARITY owns the normalized market catalogue and the market data behind it, the quote, the routing decision, the order lifecycle, positions, execution records, the settlement and reconciliation instructions an operator books against its own ledger, and the analytics over all of that.

THE VENUE owns liquidity, the execution of a contract, the wording of the market it authored, the source it resolves against, and its own settlement mechanics.

Two consequences are worth stating outright. Parity does not warehouse event risk: it does not take the other side of a customer’s position. And Parity does not hold or need a customer cash balance — a filled order or a resolved position produces an amount the operator applies to its own book, not a movement in a wallet here.

When an operator’s customer trades through Parity, Parity records one identifier for them: the operator’s own id for that customer, together with the operator it belongs to and whether that customer is active or suspended. The identifier is opaque to us and scoped to the operator — the same string sent by two operators is two different customers and always was.

Where the embedded interface is used, a short-lived session record is also written: the operator, that same customer identifier, the origin the session may be presented from, an interface language, a region hint, the operator’s theme settings, an expiry and, if it was ended early, a revocation time. The session token itself is never stored; only a hash of it is, so the row can be found without the credential being held.

PARITY DOES NOT INHERENTLY RECEIVE OR HOLD a customer’s legal name, their email address or username with the operator, a postal address, a date of birth, a password or password hash, or any bank, card, wallet or deposit credential. There is no column for any of them on the customer record. Those live with the operator, which is the party that verified them.

The exception is worth being explicit about: if an operator puts something identifying INTO the identifier it sends, or into a support message, then Parity holds whatever the operator chose to put there. That is an operator’s decision about its own customers’ data, and an operator integrating should send an opaque id.

Parity holds the record of what was quoted, ordered and settled: quotes, orders and order intents, fills, fees, positions and exits, settlements, collateral movements, ledger entries, the full state history of each order, webhook events and their delivery attempts, and the reconciliation feed built from all of it. Every row is keyed to an operator and, where it concerns a customer, to that operator’s identifier for them.

These are financial records, and they are kept for the reason financial records are kept: they are what an operator reconciles its own book against, and they are the only answer to a dispute about what happened. A settlement that cannot be evidenced is a payout nobody can prove was owed.

Parity also derives analytics from these records — volume, exposure, P&L, catalogue performance — for its own operation and for the operator’s view of its own tenant. An operator sees its own traffic and no other operator’s.

If you use the contact form on this website, what you type is stored so it can be answered: your name, your work email address, your company, your message, and any reference identifiers you choose to include — an operator name, an operator-scoped user id, a quote, order or market id.

It is used to reply to you and to investigate what you reported. It is not a marketing list, it is not enriched against third-party data sources, and it is not shared for advertising.

Do not put a password, a private key, an API key or a payment credential into that form. Parity will never ask you for one, and anything sent in a message is stored as the message.

A small number of people sign in to Parity’s admin and operator portal. For them Parity holds an email address, an optional display name, a password hash, an account status and a last-login time. There is no public signup; accounts are created by someone already trusted.

Sessions are short — hours, not days — and the session token is stored only as a hash, never as the token itself. A session row also records the IP address and user agent it was used from, and a failed sign-in is rate-limited against an email address and an IP.

Administrative actions are written to an append-only audit log that records who acted, what they acted on, and the IP and user agent behind it. Values that look like secrets are redacted rather than recorded. That log is deliberately protected against deletion, which is a security property and also, honestly, a retention one — see below.

Parity’s analytics are its own, computed on its own servers by querying the records described above. There is no third-party analytics package, no advertising network, no tag manager and no session recorder anywhere on this site, and the content policy the site serves does not permit one to be added quietly.

One additional record is written per API request an operator makes: the operator, which key was used, the route, the method, the outcome, the status code, the latency and a timestamp. It carries no IP address, no user agent and no user identifier, and identifiers inside a URL are replaced with a placeholder before the row is written rather than after.

Four preference cookies may be set — colour mode, accent colour, language and region — each recording a choice you made by pressing a control. A fifth cookie exists only after a successful sign-in to the portal. They are listed individually, with lifetimes, in the cookie policy.

Ordinary web-server request data — the URL, a timestamp, an HTTP status, and the IP address and user agent your browser sends — is processed to serve the page and appears in application and platform logs. Parity does not use it to build a profile of you, does not join it to any other data, and does not sell or share it for advertising.

Market artwork is loaded by your browser directly from the image hosts that publish it, including provider CDNs and Wikimedia. Loading an image discloses your IP address to that host, as it does on any site that shows a remote image. Market DATA is fetched server-side; your browser does not contact those providers for it, and typefaces are served from this site rather than from a font network.

The self-guided demonstration keeps its illustrative wallet and its session clock in your own browser’s storage. That wallet is a property of the demonstration, not of the product — an operator’s real positions are durable rows on our servers, as described above.

The demonstration does generate one value that reaches us. Your browser makes a random label for itself and reuses it, and demonstration quotes and orders are recorded on our servers against that label so one visitor’s do not mix with another’s. It is a label and not a credential — it protects nothing, unlocks nothing, and is not joined to anything else about you. Clearing site data discards it, and the next visit invents a new one.

Hosting and the database run on infrastructure providers under contract.

Three deletion rules are actually enforced by running code, and they are worth naming exactly because they are the only ones: market price history is thinned after about a week and deleted after about ninety days; an embed session row is deleted about a day after it expires, so there is no standing record of which of an operator’s customers opened a tab and when; and the failed-sign-in counters for an email address and an IP are cleared as soon as that sign-in succeeds.

EVERYTHING ELSE IS RETAINED INDEFINITELY. Orders, positions, settlements, ledger entries, the customer identifier mapping, portal session records and the security audit log are not deleted or anonymized by any scheduled job, because no such job exists. This page would rather say that than publish a schedule nothing enforces.

That is a defensible position for financial records — they are the evidence behind money that moved — and a decision still to be made for everything else. A production deployment carrying an operator’s traffic needs a named data controller, a lawful basis, an agreed retention schedule and a documented route for data-subject requests. Those follow from the entity and jurisdiction decisions that have not been made, and this page does not assert them.

If you are an operator’s customer, your operator is the party that holds your identity and is where a data-subject request starts. It knows which customer you are; Parity holds an id that is meaningless without them. Where an operator asks us to act on a record, we can act on it by that id.

If you are an operator, a question about your tenant’s data, or an instruction about it, comes to us directly through the contact form.

Operational information. This page describes how Parity operates today. It has not been reviewed by legal counsel and is not a contract.

A live commercial deployment needs a named contracting entity, a governing law and jurisdiction, and a jurisdiction-by-jurisdiction analysis of where event contracts may be offered and by whom. Those decisions have not been made. This page names them as outstanding rather than filling in a plausible answer, because an invented one is the detail that gets checked.

If you are evaluating Parity commercially, ask for the current draft of the agreement. That, and not this page, is what would bind either of us.