Privacy notice

Oxon Capital Limited is the controller of the personal data described here. Registered in [JURISDICTION], company number [COMPANY NUMBER], registered office [REGISTERED ADDRESS]. Data protection contact: info@oxoncapital.co.uk.

An account holds the following, and nothing else. This is the whole list, taken from the table itself.

username

The name you sign in with.

display_name

How you are addressed in the product.

email

Used to sign you in again, to reset a password, for billing notices, and for alerts if you choose email as a channel.

company

Optional. What you typed, if anything.

password_hash

A one-way hash. Your password itself is not stored and cannot be recovered from it, which is why a reset is a new password rather than a reminder of the old one.

status, created_at

Whether the account is active, and when it was made.

pro_attestation

If you have made the professional-investor self-attestation: the date you made it and the version of the wording you agreed to. Nothing else.

Which monitors you can open is held separately, as one row per account and monitor, with a note of where the access came from (a subscription, an administrator, or a complimentary grant) and when it was granted.

Signing in creates a session record holding an opaque random token, your account reference and two timestamps. The token is sent to your browser as a cookie called oxon_session, which is HttpOnly (JavaScript on the page cannot read it), Secure (it only travels over HTTPS) and SameSite=Lax. It lasts 30 days. Expired session records are deleted from the database when the service restarts.

Asking for a password reset creates a single-use token with an expiry, which is consumed the moment the new password is set.

One other cookie exists and it is described in section 8. There are no others: no advertising cookie, no analytics cookie and no third-party cookie is set anywhere in this product.

Your card details never reach an Oxon server. When you subscribe, the browser goes to a checkout page hosted by Stripe on Stripe's own domain, and the card number is entered there. We are told afterwards that a payment succeeded, not what was used to make it.

What we do hold against your account:

the plan and what it covers

Which plan, which monitors, the interval, and the amount and currency in whole cents.

Stripe's own references

The customer and subscription identifiers Stripe uses. They let us ask Stripe about your subscription; they cannot be used to charge anything.

status and dates

The subscription status Stripe reports, copied as it stands, plus the trial end, the period end, whether it is set to cancel, and when a first real payment landed.

a coupon code

If you used one.

the checkout attempt

One record per attempt, including the email you gave, so a retried redirect or a repeated webhook cannot create a second account or a second subscription.

provider events

Each notification Stripe sends us is stored under Stripe's own identifier so a repeat delivery is recognised and dropped rather than processed twice.

a record of money emails sent

Which billing email went to which account and when, so a failed-payment notice is never sent twice and never missed.

Stripe is a separate controller for the payment itself and has its own privacy notice. [LINK TO THE STRIPE NOTICE, AND CONFIRM THE CONTROLLER OR PROCESSOR POSITION].

Daily, weekly and monthly digests are off unless you turn them on. Existing catalyst alerts keep their saved setting when this feature is introduced. Each product and each delivery channel can be turned off from your account page.

email

Uses the address already on your account. Nothing extra is stored.

telegram

The numeric chat identifier Telegram gives us when you link a chat, and the date you linked it. Linking uses a single-use token that expires in 48 hours. We do not receive your Telegram username, phone number or contacts.

whatsapp

The phone number you enter, in international format, and the date a test message was accepted for it. A number is only treated as deliverable once a real send has been accepted, because a typo would otherwise deliver your alerts to a stranger. Your account page shows only the last four digits.

web push

The push subscription your browser creates: an endpoint address at your browser vendor's push service, two keys the browser generates so the message can be encrypted to it, and a short description of the browser. One record per device. None of it identifies you beyond the account it hangs off.

Your preferences include four product switches; the email and Telegram choice for each digest; whether that digest combines all your accessible subscriptions or arrives as one separate edition per tracker; and, per monitor, whether catalyst alerts are on, which channel they use, how important an item has to be, any sources you have muted, and whether that monitor's news appears on your home page.

Each alert that is due to you is written as one record holding the item's title, its link, its source, the channel it went out on, whether it was delivered, and any delivery error. That record is what stops the same event reaching you twice down two different channels.

A digest also keeps its period, channel, optional tracker scope, attempt count, acceptance time, number of included developments and a content fingerprint. The fingerprint is not the message text; it lets us identify which assembled version the delivery service accepted.

Conversations with the assistant are saved so you can come back to them. A thread holds its title, the monitor it was opened from and its timestamps; each message holds the text, and an answer additionally holds the sources it cited, any charts or maps it drew and how hard the desk worked on it.

Your questions are sent to an AI model to be answered, and to a search service where the question needs the live web. A second copy of the conversation is kept by our research service under an opaque thread identifier with no account name attached, so that a follow-up question knows what the previous one was about.

You can delete a thread from the assistant's history at any time.

Selecting a term or a passage and asking for an explanation is answered in place. We keep a record of every one of those, including the ones that produced no answer, because a surface that answers fifty times in a session and stores nothing cannot later say what the reader was told.

The record holds your account name, which page you were on, what kind of thing you asked about, the answer we gave, which model gave it and how long it took. What you actually highlighted is stored only as a one-way hash and never as text. That is deliberate and it is the design rule behind the whole feature: what Oxon said is ours and is the thing a later question is about, and what you happened to select on the page is yours. The hash still lets us recognise the same term being asked about twice; it cannot be turned back into what you selected.

Before anything leaves your browser it is also scrubbed of email addresses, bank and card number shapes and phone-number shapes, and scrubbed again on our side, because a check that runs only in the browser is a courtesy and not a boundary. The feature is switched off entirely on the pages that show client data: the administration screens and your own account page.

These explanations never appear in your assistant history and are not used to build any profile of you.

Oxon issues trackable share links so it can tell which introduction produced interest. Opening one records a visit. This is the only page-visit logging anywhere in the product.

oxon_vid

A random identifier stored in your browser for a year, used only to tell a returning visitor from a new one on the same link. It is not tied to an account and it carries no information about you.

ip_hash

Your IP address is never stored. What is stored is a salted, truncated one-way hash of it. It cannot be reversed into an address.

user_agent, referer

The browser string your browser sends, and the page you arrived from, if any.

If you write to us through a contact or interest form, we keep what you sent: an email address, a name, a firm, the message, and which page you sent it from.

This section is short because the list of things that are absent is genuinely short, and each of them was checked against the code rather than asserted.

• ·There is no analytics script on any page of this product. No Google Analytics, no tag manager, no Plausible, no PostHog, no Hotjar, no Mixpanel, no Segment.
• ·There is no advertising tag and no tracking pixel, from Meta or anyone else.
• ·We do not sell, rent or share your data with anybody for their own marketing.
• ·We do not build a behavioural profile of you and nothing here makes an automated decision about you.
• ·We do not store your card number, your password, your IP address in the clear, or the text you highlight for an explanation.

Only these, and only for the thing named against each. There is no other recipient.

Stripe

Payments. Takes your card details directly, on its own pages, and tells us the outcome. Also sends the receipts and runs the billing portal you manage your subscription from.

Hostinger

The mail server our outbound email is sent through. Sees the address and the contents of any email we send you.

Telegram

Only if you link a Telegram chat. Sees the alerts we send to that chat.

Meta (WhatsApp Business Platform)

Only if you add a WhatsApp number. Sees the number and the alerts sent to it.

your browser vendor's push service

Only if you turn on web push. Apple, Google or Mozilla depending on your browser. It routes the message; the contents are encrypted to keys your own browser generated.

our AI provider

The endpoint that runs the model behind the assistant and the in-place explanations. It receives your question and the material from the page needed to answer it. The model used is MiMo V2.6 Flash RL, reached through one provider.

our own search service

Runs on our own servers. Where an answer needs the live web, it makes the searches, which means the search terms reach the public search engines it queries.

our hosting provider

Runs the servers everything above sits on.

Everything above is held in Oxon's own databases on Oxon's own servers, except where a third party in section 10 necessarily holds its own copy. Screenshots filed by an administrator through the internal issue tool are stored as files on the same servers.

What the software does today, stated exactly: expired sign-in sessions are deleted when the service restarts; password reset tokens and chat-linking tokens are single-use and expire; the share-link visitor identifier lasts a year in your browser. Everything else is kept until it is deleted, and there is no scheduled deletion job.

• ·Passwords are stored as one-way hashes, never as text.
• ·The sign-in cookie cannot be read by page scripts, only travels over HTTPS, and expires.
• ·Card details never reach our servers at all.
• ·IP addresses are stored only as salted one-way hashes.
• ·The text you highlight for an explanation is stored only as a hash, and is scrubbed of personal-data shapes on both sides before it is sent anywhere.
• ·Administration screens are gated separately from ordinary accounts, and the in-place explanation feature is switched off on every page that displays client data.

No system is perfectly secure. If you find a weakness in this one, write to info@oxoncapital.co.uk and we will treat it seriously.

In practice, today: you can see and change your account details, your notification preferences and your linked channels from your account page; you can delete any assistant thread; you can unlink Telegram, remove a WhatsApp number or turn off web push at any time; and you can ask us for a copy of what we hold, or ask us to delete it, by writing to info@oxoncapital.co.uk.

When this notice is in force it will carry a date and we will say how a change is notified. It is a draft, so it carries a draft marker instead. What the service is and what you agree to by using it are on the terms page.

What a solicitor still has to answer

Every gap marked in the text above, gathered here. Nothing on this list has been guessed at anywhere on the page.

1. 1.Controller identity: jurisdiction, company number, registered office.
2. 2.ICO registration, whether a data protection officer is required, and the supervisory authority for complaints.
3. 3.The lawful basis relied on for each purpose in sections 2 to 8.
4. 4.A retention schedule per category, and the statutory retention for billing records. There is no retention policy today.
5. 5.The transfer mechanism for each recipient outside the UK, starting with the AI provider, which receives free text.
6. 6.Which processing agreements are signed, with which of the recipients in section 10.
7. 7.The hosting provider and where its servers are.
8. 8.The statutory rights list, the response time limit and the complaint route.
9. 9.A breach notification procedure.
10. 10.Whether Stripe is a controller or a processor here, and a link to its own notice.
11. 11.Whether a cookie banner is required given that the only cookies set are the sign-in cookie and the share-link visitor identifier, and neither is used for advertising.