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 rather than 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.

The analytics behind the product are Parity’s own, computed on its own servers by querying the records described above. The operator portal, the admin views and every figure in them are produced that way, with no third party involved in making them.

The marketing pages of this website are a separate matter, and this page used to overstate them. It said there was no third-party package, no advertising network and no tag manager anywhere on this site. That is no longer true, and the mechanism is worth stating rather than the boolean: those pages can carry a Google Analytics tag and carry a visitor identification tag, described in the next section. Each is off unless a key for it is configured and renders nothing at all without one, and the content security policy this site serves names the exact hosts each one may reach, so a third tag cannot be added quietly. A script host the policy does not name is refused by the browser rather than loaded.

None of it runs on the product. The market catalogue, a position or an order you are looking at, the embedded interface an operator’s customers use, the admin and the operator portal carry no visitor identification tag: the list of pages it may run on is written down, it holds the marketing pages and nothing else, and a page not on that list is refused rather than assumed. The admin, the portal and the sign-in page are refused twice over, because they also serve a stricter policy that admits no third-party host at all.

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.

This website runs RB2B, a visitor identification service, on its marketing pages. It is not analytics, and the difference is the point: analytics counts visits, and this attempts to resolve a visit to a named person and the company they work for by matching signals from your browser against data its partners already hold. What it produces is a lead record delivered to Parity, not an aggregate.

When you visit or log in to our website, cookies and similar technologies may be used by our online data partners or vendors to associate these activities with other personal information they or others have about you, including by association with your email. We (or service providers on our behalf) may then send communications and marketing to these email addresses. You may opt out of receiving this advertising by visiting https://app.retention.com/optout.

What that amounts to on this site, measured by loading the script and watching it rather than by reading the vendor’s description of it: a long-lived random identifier is stored in your browser, your IP address is looked up against a geolocation service and the answer is kept in a cookie, identifiers are exchanged with several identity-resolution partners, and the visit is then sent to the vendor. The cookies involved, including the ones those partners set on their own domains, are listed individually with their lifetimes in the cookie policy.

It runs on the marketing pages only: the home page, the product and industry pages, the pricing, security, contact and careers pages, the blog, the case studies, the developer documentation and these policies. It does not run on the market catalogue, on a market, position or order page, in the embedded interface an operator’s customers use, or on the admin or operator portal.

There is no consent banner on this site. That is a deliberate decision rather than an oversight, and the opt-out above is the route out of the advertising this feeds.

Four preference cookies may be set, recording your colour mode, accent colour, language and region, each of them the result of a choice you made by pressing a control. A fifth exists only after a successful sign-in to the portal, and a sixth only once you ask for a quote in the self-guided demonstration. The visitor identification tag described above sets several more, some of them by its partners on their own domains rather than by us. All of them 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 give your browser one identity that reaches us. The first time you ask for a demonstration quote, our server issues a random token in the parity_demo_session cookie and creates a demonstration identity for it, and your demonstration quotes and orders are recorded against that identity so one visitor’s do not mix with another’s. The token is made from random bytes and derived from nothing about you. We store only a hash of it, alongside when it was created, when it was last used and when it expires. It is not joined to your name, your email, your IP address or anything else about you. Clearing site data discards it, and the next quote starts a new identity.

Hosting and the database run on infrastructure providers under contract.

The demonstration can show suggestions on the main markets board, and not when a category, a search or another filter is chosen. "Where you left off" lists bets you priced in the last three days but did not place. On a wide screen, when there are only a few of those, the same row is completed with "For you": other open markets in the same league, or with no league the same category, as markets you opened, priced or bet on recently. They are built only from the demonstration identity described above, so a browser that has never asked for a demonstration quote has none and sees no suggestions. Opening a market page never creates an identity just to record the visit.

Two things feed them. The first is the quotes and orders already recorded against your demonstration identity: nothing new is collected to know you started a bet. The second is a list of the market pages you opened, which is new. For each one it holds a market id and the time you opened it, and nothing else: no title, no price, no IP address, no user agent, no referrer. The list is held in the memory of the server that answered you rather than written to the database. It keeps at most thirty entries per identity, drops each after seven days, and is discarded whenever that server restarts.

Suggestions are worked out on our servers from those two sources and nothing outside them. They are never shared with an operator, an advertiser or the visitor identification tag, which does not run on the markets pages. A suggestion never shows the price you were quoted before. It shows the price available now, and pressing it asks for a fresh quote. Pressing a "Where you left off" suggestion also fills in the stake you had chosen, which is carried in the address of the page it opens and which you can change before anything is quoted.

You can hide them. The X beside the rows hides them for the rest of this visit only: it keeps one setting in this tab’s own storage, deletes nothing, and the suggestions return on your next visit. To remove the history itself, clear this site’s data. That discards the demonstration cookie and with it your demonstration identity, so the next quote starts a new one with no history and nothing can connect the earlier history to your browser again. The list of pages you opened is then dropped within seven days, or sooner if the server restarts. Quotes and orders already placed are trading records and are not deleted.

Operators’ customers are not included. The embedded interface uses the operator’s own identifier for a customer and records no page views.

Five 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; a demonstration session row is deleted about a week after it expires; the list of market pages a demonstration identity opened drops each entry after seven days and does not survive a server restart; 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. It is 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.

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.