Privacy notice

Controller and privacy contact

Cambridge TCG Limited (company number 15680297) is the controller for the processing described here. Our registered office is 60 Tottenham Court Road, Suite 4583a, Fitzrovia, London, United Kingdom, W1T 2EW.

For a privacy question, rights request, public-data correction or removal request, email [email protected]. Please put “privacy” in the subject where practical.

Personal data we use

• Account and sign-in data: email address, username, display/profile fields, settings, functional-cookie choices and account state. Sign-in uses an emailed magic link, so Cambridge TCG stores no account password. A one-time token is stored with the email that requested it. If Google sign-in is configured and you choose it, Google supplies the verified email, name, profile image and provider-account identifier; the account link can also store OAuth access, refresh and ID tokens, scope, type and expiry/session metadata.
• Communications: direct messages, support correspondence, notification preferences and the context needed to answer or moderate them. Direct messages are available to their participants and authorised support tools; a relevant counterparty may start a conversation in the situations described in the publication section below.
• Orders and peer transactions: products or cards, listings, bids, swaps, prices and payouts, names, delivery addresses, shipping and tracking details, transaction status, messages, dispute material and evidence. A seller, buyer or swap counterparty receives the details needed to fulfil the transaction. A Cambridge-verification or escrow flow may instead direct a shipment to Cambridge TCG.
• Stripe payments and payouts: Stripe receives payment-card and checkout details. Cambridge TCG receives transaction, customer, session, payment, refund and dispute identifiers and statuses, but not the full card number. The retired paid-membership system may also retain the card brand and last four digits that Stripe supplied for the former account billing display; Cambridge TCG does not retain the full card number. Sellers who start Stripe Connect onboarding give Stripe identity, business, bank-account and payout information; Cambridge TCG stores the connected-account identifier, capability/status and transfer records needed to operate payouts.
• Optional Cambridge identity verification: new submissions and document uploads are paused by default. A deployment can enable them only after an explicit private storage review. When enabled, the flow accepts full legal name, date of birth, UK address, optional phone number, and uploaded government-identity, proof-of-address or other supporting image/PDF files selected by the participant. It rejects bank details. Earlier submissions may still contain a sort code, account number and account name until reviewed cleanup or a valid deletion request. Existing owner-scoped document reads and deletion remain available while new submission is paused. A legacy file reference that does not match the account that owns the record is not opened and needs support-assisted inventory and removal. Authorised administrators can review the submission and outcome. Files are stored with our AWS infrastructure. This is separate from Stripe Connect verification and currently has no automatic effect on trading or trust presentation.
• Optional external reputation: the marketplace, public profile URL or username, a verification code, public profile facts returned by the named marketplace, check times and result. Cambridge TCG fetches the user-nominated public profile and may recheck it about every 90 days. A verified result can contribute to the displayed trust score.
• Collector and community data: private collection and wishlist records, explicit trade intent, follows, blocks, reviews, trust and moderation state, showcase cards, achievements and the separately controlled publication receipts described below. Private collections and wishlists are not made public by a profile-publication choice.
• Collectives and directory data: organisation slug, name, kind, region, languages, description, house rules, steward account, members, invites and publication settings. Steward and membership records remain in account management; the public directory query does not select them.
• Saved and public decks: a signed-in deck save stores its identifier and slug, name, leader, card entries and quantities, notes, tags, public/private flag, view count and record times. The private card snapshot can contain catalog image and price fields. Public deck responses withhold those image/price values and the author account ID, as explained in the publication section below.
• Testnet wallet-link data: the public Base Sepolia address and the detailed proof records explained in the wallet section below. A public blockchain address can be correlated with the Cambridge account that links it, even though Cambridge does not publish a wallet directory.
• Requests, security and logs: IP address, User-Agent/browser description, request time, route, response and rate-limit or security events may be processed in infrastructure, access and security logs. Cambridge TCG does not create an application-level analytics profile from ordinary page visits, but hosting and security logs can still exist.
• Optional PRISM Signals Telegram preview: if the preview is configured and you open its bot, Telegram sends Cambridge TCG a webhook update that can contain a Telegram user/profile identifier, profile or display-name fields, private-chat identifier, message and command text, update/message identifiers, language or username fields Telegram includes, and—if misrouted—payment or refund fields. Cambridge verifies the webhook secret, reads at most 32 KiB, uses only the update id, private-chat or pre-checkout id, chat type, bounded command text, and presence of payment fields needed for the fixed response, and processes them in memory. This preview creates no application database row, account link, analytics profile, entitlement or payment record. Vercel can still process ordinary access and security metadata. Telegram separately processes the bot chat and update under its own service and privacy terms. Do not use the preview for personal, card, listing, seller or payment information.
• Optional PRISM Signals closed-beta interest: after signing in, you can affirmatively ask Cambridge TCG to store your existing account ID, the product IDprism-signals, one or both bounded preferences of web and Telegram, the exact beta-contact wording version, and request, update and expiry times. The beta table stores no new copy of your email address; Cambridge TCG may use the email already held on your account only for a PRISM beta invitation or status update you requested. A Telegram preference does not supply a Telegram identity, authorise Telegram outreach or link an account. Presence of the row is not general marketing consent, a purchase, an invitation, a queue position, product access or an entitlement. You can inspect the exact owner-scoped state and delete the complete row without penalty from the same signed-in page.
• Optional PRISM Signals Stripe sandbox: when the separately gated test is available, Stripe's hosted Checkout collects the test customer, billing address, email and payment-method details entered there. Cambridge sends Stripe a fixed sandbox type and random attempt reference, not your Cambridge user ID, stored account email, subject/entitlement reference or internal offer scope. Cambridge stores your account-to-test-subject and entitlement-generation mapping, frozen Checkout attempt, and the Stripe test customer, Session, subscription, Price, invoice, payment and refund identifiers and statuses needed for idempotency, access, cancellation and repair. Signed-event receipts store the event identifier, type, mode, outcome, bounded review reason and SHA-256 digest, not the full webhook payload. The dedicated webhook necessarily receives and parses the signed Stripe event in memory before discarding it; that transient event can include Checkout customer details such as test email, name and billing address supplied to Stripe. The generic entitlement ledger receives only random or HMAC-derived opaque references. Cambridge never receives the full card number. This sandbox accepts no live Stripe event and unlocks only a fixed synthetic test surface.
• Optional collector observations: the owner-only witness notebook contains the card SKU, action, amount and currency, condition, date, sharing choice and optional SHA-256 fingerprint. Non-private sharing modes record permission for a possible future projector only. Raw rows remain owner-only, public projection is paused and no aggregate has been released.
• Coverage Hunt records: voluntarily submitted words, citation pointers, role and time; its history stores no operator email or user ID.

Most data comes from you. We also receive transaction and status data from Stripe, fulfilment or dispute information from a trading counterparty, optional account/profile and OAuth data from Google when you choose configured Google sign-in, public facts from a marketplace profile you ask us to check, wallet-verification results from the configured RPC service where needed, an optional Telegram update when you choose the configured PRISM preview bot, an optional account-scoped PRISM beta request when you choose to make one, and records created by our own service.

What is required and what is optional

• An email and functional sign-in data are required to create and use an account. Without them, you can still browse public pages but cannot use account tools.
• Transaction, payment and delivery details are required only when you request the relevant order, trade, auction, swap, payout or shipped reward. Without the required details, Cambridge TCG or the counterparty cannot complete that service.
• Information required for tax, fraud, sanctions, accounting or other legal checks must be provided where that obligation applies; the transaction or payout may be refused or paused if it is missing.
• Google sign-in is optional when it is configured. You can use the email magic-link route instead; declining Google changes no other account feature.
• The PRISM Signals closed-beta request is optional and uses a separate, initially unticked affirmation. Declining or withdrawing it changes no account feature and carries no penalty. A channel preference says only where you might prefer to use a separately offered product.
• Public profile, review and activity publication, messaging, collective-directory listing, Cambridge identity verification, external-reputation checks, saved/public decks, collector observations and future-projector permission, and testnet wallet links are optional. Declining affects only that feature or any trust contribution expressly attached to it.
• Do not include personal data about another person in collective directory fields. A steward cannot make that acceptable merely by selecting the publication checkbox.

Why we use data and our lawful bases

Our legitimate interests are service and transaction security, fraud and abuse prevention, dispute handling, moderation, reliability, record integrity and the defence of legal claims. We consider whether those interests can be achieved with less data and the likely effect on people. You can object; we will reassess the balance unless the law requires the processing or compelling grounds override the objection.

Automated rules and human review

Cambridge TCG uses rules to calculate and present trust scores and tiers; set transaction limits, escrow routes, physical-inspection requirements, trust-based commission rates and payout holds; enforce auction, payment and trade states; match only explicit card-level trade intent; apply rate limits; and raise security, fraud or moderation flags. Inputs can include account age and state, completed or cancelled transactions, trading volume, trust-weighted reviews, verified external reputation, returns, disputes and chargebacks, transaction value, card category, explicit listing/wishlist choices and risk signals.

Fraud signals have a specific automatic downstream effect. Each unresolved signal at medium, high or critical severity subtracts 20 points the next time the trust score is calculated. A lower result can reduce per-transaction and daily limits, change the displayed tier or trust-based commission rate, route a future trade through stricter escrow or inspection, and lengthen a hold on a future seller payout. The signal row’s stored auto_actionlabel is not itself executed: current detection does not directly suspend the account or stop an already-earned payout. An operator can resolve or dismiss a signal; recalculating the score then removes that signal’s 20-point deduction.

A rule can reject or limit an action, change the route or terms of a trade, require inspection or escrow, delay a payout, change trust presentation, or affect whether a listing/account is discoverable. Whether an outcome has a legal or similarly significant effect depends on its real context and impact; Cambridge TCG does not treat this list as a conclusion that the statutory safeguards for solely automated decisions can never apply. If a rule blocks or materially changes a service, email the privacy contact to request an explanation and human review, express your view, or challenge inaccurate input data. Where those statutory safeguards apply, the review must be capable of correcting inputs and changing the outcome rather than merely repeating the automated result.

There is not yet a durable in-product decision-review case queue, assigned reviewer or published service level. Email is the current request channel, but a support link alone is not evidence that human intervention is operational. For that reason, production rejects new orders, offers and acceptances, auction commitments, swaps, lot commitments and automatic pricing-rule commitments by default. The pause does not block payment, shipping, receipt, cancellation, return, dispute, refund, payout, evidence or revocation steps for an existing obligation.

Public features, choices and their reach

For versioned person, activity and directory choices, Cambridge TCG stores the current notice version and acceptance time while the choice is on. Deck publication currently stores an unversioned public/private flag and deck update time, not a separate notice receipt. Withdrawal stops future publication by Cambridge TCG and clears an active receipt where the feature is designed that way; it cannot make someone else forget, return or delete a copy they already obtained.

Testnet wallet links and RPC disclosure

Wallet linking is optional and currently limited to Base Sepolia; Cambridge TCG does not accept assets through this feature. We keep the public Base Sepolia address, chain, proof method, verification times, signature fingerprint, and the exact five-minute standard wallet-signing message (EIP-4361), including its one-use code and random request identifier. We also keep the bounded verification-attempt count and attempt times. A separate one-way digest binds the challenge to the Cambridge sign-in session; that digest is not placed in the wallet-visible message. The raw session token and wallet signature are not retained. This proof is not identity, KYC, asset ownership, or permission to move funds; it shows only control of the address at that time.

A public blockchain address and its public activity may be correlated with the Cambridge account that links it. Cambridge TCG first checks an ordinary wallet signature locally. Only after that fails does the configured Base Sepolia network service receive the public address to check whether it belongs to a smart wallet. It receives the exact challenge message and submitted signature only when the address has deployed smart-wallet code or the signature contains a locally recognised smart-wallet marker (ERC-6492). Cambridge first checks that the service reports Base Sepolia. Cambridge TCG will not enable remote smart-wallet verification unless the wallet screen identifies the configured RPC provider and links its privacy information before a submission can call it. If no provider is explicitly and validly configured, smart-wallet verification stops instead of using an unnamed default. The wallet feature may remain disabled until these conditions are met.

What we do not collect or do

• Cambridge TCG stores no account password and does not receive the full payment-card number entered in Stripe Checkout.
• We do not sell personal data or share it for third-party advertising.
• We run no marketing, advertising or third-party analytics cookies on the storefront.
• We do not retain a wallet seed phrase, private key, balance or submitted signature.
• If you select a witness-notebook receipt, the browser computes a SHA-256 fingerprint locally; the receipt file, merchant, name, location and free-text notes are not sent to Cambridge TCG.

Who receives data

• Google receives an OAuth sign-in request when Google is configured and you choose that button. It returns the account/profile and OAuth material described above. Google also processes ordinary request and device metadata under its own privacy policy.
• Stripereceives payment, checkout and, where requested, Connect identity, bank and payout onboarding data. Stripe may act as a controller for parts of its regulated payment and verification processing. See Stripe’s privacy centre.
• Amazon Web Services hosts database and object-storage workloads, including optional identity documents, and may send service email through SES. A separately configured email-delivery service receives addresses and message content when it is used instead.
• Vercel hosts the web application and processes ordinary network, access and security request metadata.
• Cambridge TCG's authorised operators and email-delivery provider may receive the existing account email and limited PRISM invitation/status message if Cambridge sends the specific beta contact you asked for. The beta-interest table itself does not copy the email, and the request is not used for general marketing.
• Telegramreceives and processes your interaction when you choose to open or message the configured PRISM preview bot, and sends the resulting update to Cambridge TCG's Vercel-hosted webhook. Telegram is an independent service; see its privacy policy. No Telegram bot is advertised unless the separate fixture configuration and clean non-payment/privacy-wired posture are present.
• A configured Base Sepolia RPC provider receives the limited wallet-verification data described above when remote verification is required. Cambridge TCG will keep that remote path disabled unless the wallet screen names the active provider and links its privacy information before the request.
• Transaction counterparties receive the names, delivery addresses, tracking, messages and dispute/fulfilment information necessary for the relevant peer trade, auction or swap. Cambridge TCG provides it for that transaction; a counterparty is independently responsible for any later use it makes of the information.
• A marketplace you nominate receives ordinary request metadata when Cambridge TCG checks the public profile URL for external reputation.
• The public, search engines, crawlers and third parties receive only material you separately choose to publish, subject to the boundaries above.
• Professional advisers, insurers, payment/fraud partners, courts, regulators or law-enforcement bodies may receive relevant data where necessary for advice, a claim, security, fraud prevention or a legal obligation.

International transfers

Suppliers and infrastructure may process data outside the United Kingdom. In particular, some Cambridge database and object storage currently uses AWS in the United States, while Google, AWS, Vercel and Stripe operate international services and subprocessors. Their provider terms state that a recognised mechanism applies where UK restricted-transfer rules require one, such as UK adequacy regulations, the UK International Data Transfer Agreement or UK Addendum to standard contractual clauses, as applicable, together with contractual and security measures. Cambridge TCG relies on those terms for these services. The applicable route can vary by provider and subprocessor. Provider information is available in the AWS GDPR centre, Vercel DPA, Telegram privacy policy and Stripe privacy centre. Contact us for the current safeguard relevant to your data.

Cookies and browser storage

The storefront uses functional cookies to provide a requested service or remember a choice:

• Auth.js cookies — a session token keeps you signed in; temporary CSRF, callback and sign-in cookies protect and complete authentication. The session-token cookie is configured for a maximum of 30 days and is removed earlier on sign-out or expiry. Auth.js uses names in the authjs.* family, including authjs.session-token, authjs.csrf-token and authjs.callback-url. Optional Google sign-in can also use state, nonce and PKCE cookies; all three have a 15-minute maximum, while the other temporary cookies end with their browser session or sign-in flow. Secure production names may use __Secure- or __Host- prefixes.
• display-currency — remembers the requested display currency for up to one year.
• text-mode and lang-mode — remember reading and language-display choices for up to one year.
• theme and tone — remember an explicit visual theme and writing-style choice for up to one year; choosing defaults removes them.
• banner-dev-notice — remembers a dismissed site notice until the browser closes.
• ctcg-guest-id — a retired PVE guest cookie. Current code does not use it and expires it when the PVE status endpoint is visited.

Browser local storage

The storefront also uses first-party localStorage, which stays in that browser rather than being attached to every web request. Current application code does not write to sessionStorage or IndexedDB. The local-storage records are:

• market.listing-draft.v1 — the selected card and catalog snapshot, condition, intended price and quantity, return choice and save time. It is removed when the listing is posted or you reset or replace the draft.
• ctcg-deck-builder-decks — locally saved deck names, leaders, cards, quantities, catalog image/price snapshots and save times. For a signed-in person, choosing Save also sends the deck to Cambridge TCG for the cross-device saved-deck feature described above.
• ctcg-practice-battle, ctcg-practice-clears and ctcg-practice-starter — local practice-game state, cleared level numbers and the last starter choice.
• account.handle-welcome.v1:* — a per-handle marker that prevents the same welcome note from appearing again after you dismiss it.
• cambridgetcg_cart — a retired retail-cart key that current code does not create and removes when the order-confirmation cleanup runs.

Local storage has no time-based expiry. A record remains until the relevant feature overwrites or removes it, you clear this site’s browser data, or the browser evicts it. Cambridge TCG does not automatically receive a listing draft, local deck or practice state merely because it is in local storage; relevant details are sent when you submit a listing, choose a signed-in deck save, or otherwise make the corresponding request.

No storefront marketing, advertising or third-party analytics cookie is currently set, so there is no marketing-cookie consent banner. Infrastructure request logs are separate from cookies and are described above.

How long data is kept

• Orders, payments, trades and accounting records: at least six years from the end of the relevant company financial year, and longer where a law, tax enquiry, dispute or legal claim requires it.
• Account, messages, social and collective-management data: currently kept with the account until you request deletion; Cambridge TCG has not yet implemented an automatic inactive- account purge. We may retain a limited record where a legal obligation, transaction, safety issue, dispute or legal claim requires it.
• Google OAuth account links: provider identifiers and returned OAuth/token metadata are kept with the linked Cambridge account until unlinking or account deletion; an individual token can expire earlier.
• PRISM Signals Telegram preview updates: no application record is retained by the current preview; the bounded update exists in server memory only while the response is formed. Vercel access/security logs and Telegram's own bot chat/update records are separate and governed by those providers. A payment-bearing update is not acknowledged by this preview, so Telegram may retry it; the preview must be connected only to the explicitly declared clean, invoice-free test bot.
• PRISM Signals closed-beta interest: an affirmative request expires 180 days after its most recent affirmative submission. Only a new submission with the contact checkbox ticked refreshes that expiry. Withdrawal deletes the complete row immediately and without penalty. Changing the contact wording invalidates and deletes the prior row rather than silently carrying consent forward. The 180-day window is one bounded product-research cycle, rather than treating an expression of interest as indefinite. A daily authenticated retention route is configured to delete expired or invalidated rows. The owner status endpoint is read-only: it excludes expired and superseded-wording rows but does not delete other accounts' data. If the scheduled route does not run, physical deletion can wait for its next successful run or operator intervention, but an expired row is never returned or treated as active interest. Owner withdrawal still deletes that account's complete PRISM request immediately. The closed-beta-v1 mode is only a switch for new request intake and its public invitation; pausing or losing that setting does not disable authenticated owner status, withdrawal, or the retention sweep.
• PRISM Signals Stripe sandbox records: an operator-issued invitation and test Checkout, customer, subscription, invoice/grant and signed-event mappings are currently retained with the linked account while the test subscription may need status, cancellation, duplicate handling or repair. Beta interest is not an invitation. Account deletion cannot remove the owner/provider mapping while the remotely observed subscription is still non-terminal, because doing so could leave recurring test billing without a local owner or cancellation path. After Stripe termination is observed, deletion removes the directly owned invitation and mappings, subject to any limited security, dispute or legal record that must remain. Bounded signed-event receipt/audit records can retain the raw Stripe event ID and payload digest after direct owner mappings are removed; they do not retain the full event, but may remain linkable through Stripe or other auxiliary data. Canonical product-flow events retain pseudonymous opaque references after their account/provider mapping is removed; Cambridge does not claim either record class is anonymous or provably unlinkable. Cambridge has not yet enabled a live charge or claimed the six-year accounting basis for these test-only records. Invitations have explicit expiry and revocation; a shorter automatic terminal-test purge remains a launch gate before opening the sandbox beyond that bounded cohort.
• Identity verification and external reputation: the verification submission, checks and outcome are currently retained with the account and do not yet have a shorter automatic deletion schedule. You can delete each current identity-document upload or ask us to withdraw/delete optional material, including bank fields remaining from an earlier submission; a limited fraud, audit or legal-claims record may remain where justified. The upload currently stores the file before saving its database record. If that second step is interrupted, an unindexed file can remain and cannot be removed through the ordinary document screen. New uploads stay paused until Cambridge TCG has reviewed private storage and an abandoned-upload inventory or expiry process; support can also arrange an inventory of files stored for the account.
• Magic-link tokens: usable for up to 24 hours, deleted when used and pruned in bounded batches when a later sign-in request runs cleanup. There is not currently a separate maximum time by which every expired row is guaranteed to be removed. Issuance is capped at five unexpired tokens per email and 500 service-wide; a failed email reservation keeps its slot until expiry rather than permitting extra sends.
• Publication receipts: kept with the account while each choice is on to show the notice version and acceptance time. Turning a choice off clears its active receipt fields where the feature is designed that way.
• Testnet wallet proofs: a challenge can be used for five minutes, but its exact message, proof-free verification-attempt records (challenge, chain/address key and attempt time), and active or revoked link history are currently retained with the account for replay investigation and audit. There is no automatic earlier cleanup; account deletion removes all three wallet tables. We will publish a shorter reviewed schedule before a broader or payment-capable rollout.
• Saved decks: kept until the owner deletes the deck or the account. Unpublishing keeps the saved deck private and stops future public page/API responses; it cannot recall earlier copies. The aggregate view count remains with the saved deck until deletion.
• Collector observations: kept owner-only until you delete each row or the account. Deletion also removes eligibility for any future projector. Anonymous/CC0 modes currently store future-projector permission only: no public projector reads the table and no aggregate has been released.
• Coverage Hunt turns: the submitted evidence remains as the game review record. Account erasure removes the live agent identity link; later views show a deleted actor state. Ordinary agent archive is not erasure.
• Infrastructure and security logs: periods vary by provider and log type. The retention decision depends on whether the record is still needed to deliver or diagnose the service, investigate a specific security or abuse event, meet a provider/security requirement, or establish, exercise or defend a legal claim. The exact live periods have not yet been consolidated into this notice; contact us for the current period relevant to a specific request.

Children

Public catalogue and methodology pages can be viewed by anyone and may be accessed by children. Account, messaging, social publication, trading, payment, collective-directory publication, Cambridge identity-verification and wallet-linking features are not designed for people under 18. Cambridge TCG does not currently run general age assurance or record a site-wide, versioned age-and-terms assent at account creation or before all social tools. Production now defaults new account admission and new P2P commitments to paused unless an operator selects the exact reviewed release mode. That reversible release control is not age assurance, so the service still cannot claim that every account holder is an adult. When the optional identity-verification form is enabled, it rejects a declared date of birth under 18; that is not site-wide age verification. A person under 18 should not submit personal data to or use those account features. A parent or guardian can email the privacy contact to ask us to locate and remove a child’s data, subject to legal retention duties.

Paused inputs and legacy records

• Account and P2P admission: production defaults new account registration and new marketplace commitments to paused. Existing-user sign-in and existing obligation/remedy steps stay available. The exact reviewed modes are deployment controls, not stored proof that a person is over 18, accepted a particular terms version or received operational human intervention.
• Identity verification: new submissions and document uploads default to paused and return an unavailable response unless the deployment explicitly enables reviewed private storage. Existing owner/admin reads and owner-requested deletion remain available for owner-scoped objects; a legacy key that fails that check is kept closed and requires support-assisted storage inventory and removal.
• Retired trade-in desk: the Cambridge TCG we-buy desk closed on 6 July 2026. The current /api/tradein/status, /api/tradein/submit, /api/tradein/quote, /api/market/sell-for-credit and /api/quotes paths return HTTP 410 before reading submitted content or trade-in database records, so they collect no new trade-in submission content. Ordinary infrastructure request logs described above can still exist. Legacy database schemas remain; this notice does not infer from source code alone whether a historical row exists. Any historical transaction record, if present, follows the transaction-retention and rights rules in this notice.
• Retired paid memberships: the paid-membership interface closed on 21 July 2026. An authenticated legacy billing endpoint can still return the signed-in account holder’s mirrored subscription status, plan, tier name, cancellation/expiry timing, card brand and last four digits, plus recent invoice summaries and links fetched from Stripe when available. It does not return the full card number. Every response, including an authentication error, is marked private and no-store.
• Retired Bounty Board phone submissions: an unfinished pilot accepted phone numbers without proving account control. It accepts no new numbers and existing records were never treated as verified. A submitted number may remain with the account until deletion.
• OG claims: the old form accepted email, marketplace, order reference, username and notes without proving ownership. New public submissions stop before reading the body or claim database. Existing claims remain available only to authorised staff for review and correction/deletion requests.
• Agent feedback and carried state: public write paths are paused. New POSTs stop before body or database reads. Older internal rows await a separately reviewed cleanup.
• PVE: new durable battles and rewards are paused. Existing owner-only progress reads remain, while old guest rows await a separate cleanup decision.
• One-click unsubscribe: current requests store the email preference, not request IP or browser description, and repeat opt-outs do not create a fresh application record. Older audit rows may contain IP and User-Agent fields and still need reviewed cleanup.
• Incomplete legacy retention: old unsubscribe-audit, OG-claim, agent-feedback, carried-state and PVE guest records do not yet share a complete automatic retention rule. Cambridge TCG is reviewing cleanup rather than claiming it has occurred.

Your data-protection rights

Depending on the circumstances, UK data-protection law gives you the right to:

• access your personal data and receive information about its use;
• correct inaccurate data and complete incomplete data;
• ask for erasure where no overriding legal reason requires retention;
• restrict processing in the situations set by law;
• object to processing based on legitimate interests and to direct marketing (Cambridge TCG does not currently carry out direct-marketing profiling);
• receive data you supplied in a structured, commonly used, machine-readable format, and have it transmitted where the portability right applies;
• withdraw consent at any time, without affecting processing already lawful before withdrawal; and
• seek human intervention, express your view and contest a qualifying solely automated decision.

Email [email protected] to exercise a right. We may ask for proportionate information to verify identity and scope. Rights are not absolute: tax/company records, another person’s rights, fraud/safety records, legal claims and other statutory exceptions can limit a request. We normally respond within one month, subject to the extensions the law permits for a complex or repeated request.

Data-protection complaints

You can make a complaint about Cambridge TCG’s handling of personal data through the same privacy email address. Put “data protection complaint” in the subject and explain what happened, which data or feature is involved and the outcome you seek. Cambridge TCG will acknowledge a data-protection complaint within 30 days, make appropriate enquiries, keep you informed where the investigation remains open, and communicate the outcome without undue delay. A complaint can include a rights request; the applicable rights-request time limit remains separate.

You can also complain to the UK Information Commissioner’s Office. See the ICO’s complaint service. We would welcome the chance to address the issue first, but you do not have to contact us before contacting the ICO.