Privacy
What we hold about you and your strategies, why we hold it, how long for, and the things we deliberately arranged not to be able to see.
Controller: DualQuant, established in the Czech Republic. Contact: support@dualquant.ai. Where your data is: on a server in Helsinki, Finland, inside the European Union -- with one exception, the intake model, set out in section 7. We have not appointed a data protection officer, because the processing described below does not require one.
1. This website collects nothing
The page you are reading sets no cookies, runs no analytics, and makes no request to any third party. There is no tracking pixel, no font loaded from someone else's server, no embedded video and no consent banner, because there is nothing to consent to.
The reports we generate behave the same way. A report is a single self-contained file with its chart embedded: opening one makes no network request at all, so nothing about which strategy you looked at, or when, reaches us or anyone else.
2. What we hold once you have an account
| Record | What it contains |
|---|---|
| Account | An account identifier, a display label, your email address if you gave one, your subscription state and your attempt balance. |
| API key | A SHA-256 digest of the key, never the key itself, plus a label and the date it was issued. We cannot show you your key again; we can only replace it. |
| Submissions | The description you sent, the plan we agreed with you, and its hash. |
| Run records | The full internal record of each verification: every check, every figure, and the report you received. |
| Attempt ledger | An append-only, hash-chained entry per attempt: your account identifier, the dataset version, and the hash of the plan, or for a company view the day and a hash of the ticker. Not the plan or the ticker itself. |
| Outcome index | Verdict-level outcomes with a salted hash of your account identifier rather than the identifier itself, so aggregate statistics cannot be reversed onto a customer. |
| Service log | Which endpoint was called and what status it returned. |
A language model reads your description, once. When you submit an idea in plain English, a model turns it into the structured plan we then read back to you for confirmation. Nothing after that point is a model: every check, figure and sentence in your report is produced by deterministic code.
That model runs at a third-party provider outside the EEA, so the text you type is the one thing about you that leaves Europe. Section 7 says exactly what is sent and on what basis. If you submit a structured condition tree through the API instead of prose, no model is involved at any point -- which is the control to use if your description is itself the sensitive part.
3. What is never recorded
These are architectural choices rather than policy promises, which is why they are worth stating separately:
- No session handle is ever written to a log. A handle is bearer-equivalent -- presenting one is presenting authority over that session -- so the application replaces it with a placeholder before writing anything, and the TLS proxy in front is configured to log nothing whatsoever. Your IP address is not recorded by either.
- No API key is stored. Only its digest, like a password.
- No brokerage credentials, account numbers, positions or balances. The platform cannot place an order and has no connection to any broker, so it has no reason to hold any of this and no field to put it in.
- No payment details. During private preview no payment is taken at all. When a payment processor is added, card details will be held by that processor and not by us.
- No run counts on the public status page. Attempt numbers are the statistical core of the service and stay behind the key.
4. Why each record exists
We hold each of these because the service cannot work without it, not because it might be useful later.
- The account and key digest let us tell who is asking and whether they have attempts left. That is the contract between us.
- The submission and run record make a verdict replayable and disputable. A verification you could not challenge would be worth very little, and challenging one means both of us looking at the same stored record.
- The attempt ledger is what makes the multiplicity correction honest. It has to be append-only and tamper-evident, including against us, or the hurdle it sets could be quietly lowered.
- The outcome index lets us say true things about the service as a whole without being able to say them about you.
- The service log is how we find out that something broke.
5. How long we keep it
Account records are kept while your account exists. Submissions, run records and reports are kept while your account exists, so you can come back to a verdict and so we can answer a question about one. Service logs are short-lived operational records and are not retained as a history of your use.
Ledger entries are permanent by design -- see the next section.
6. Deletion, and the one thing that survives it
Ask us and we will delete your account, your email address, your submissions, your run records and your reports. We will confirm when it is done.
One record cannot be deleted, and we would rather say so plainly than discover it together later. The attempt ledger is a hash chain: each entry commits to the one before it, which is what makes it evidence rather than a list we could edit. Removing an entry would break the chain for every attempt that followed, including other customers'.
What survives deletion is therefore one row per attempt, containing a random account reference, the dataset version, the hash of a plan and a timestamp. It holds no name, no email address and no strategy -- a hash is not the thing it is a hash of, and the plan itself is in the records we do delete.
We do not have to edit those rows to end the association, and we do not. The reference in them is a random string generated when your account was created; the only thing that ever connected it to you was your account record, and deleting your account deletes that. From then on the surviving rows point at nothing, the chain still verifies, and nobody -- including us -- can tell which of them were yours.
7. Who else sees it, and the one transfer out of Europe
We do not sell, rent or share your data, we do not publish, rank or show your strategies to anyone else, and we use no advertising network and no analytics provider. Two processors act for us, and they are both named here rather than described as "our partners".
| Processor | What reaches them | Where |
|---|---|---|
| Hetzner Online GmbH | Everything stored: your account, submissions, run records and reports. They host the server; they have no reason to read it and no part in the service. | Helsinki, Finland (EU) |
| The intake model provider (Anthropic, or Google as a fallback) | Only the words you typed describing your strategy, with a fixed instruction telling the model to report back what you said. No account identifier, no dataset, no run record, no report. | Outside the EEA |
That second row is a transfer of personal data outside the European Economic Area, and it happens because an intake that can read ordinary English is worth more than one that cannot. It rests on the standard contractual clauses in that provider's data processing terms, under which they act on our instructions, do not train on what is sent, and delete it on their own retention schedule.
If you would rather it did not happen at all, submit a structured condition tree instead of prose. The API accepts one directly, no model is called, and nothing about your submission leaves Finland.
Market data for our reference store is obtained from data vendors. That traffic is us fetching prices, and it carries nothing about you or your strategy.
We will disclose data if the law requires it. If that happens and we are permitted to tell you, we will.
8. How it is protected
- Everything crosses the network over TLS. The application itself is not reachable directly; a reverse proxy terminates TLS in front of it, and strict transport security is set so a first request cannot be downgraded to cleartext.
- API keys are stored as digests, so a copy of our database does not yield a usable key.
- Submissions are rules in a closed grammar, not code. We never execute code you send, which removes an entire class of risk for both of us.
- Backups of the platform's state are taken before changes that could lose it.
Stated honestly: we are a small operation in private preview. We have not been independently security-audited, and we do not claim a certification we do not hold. Judge the architecture above on what it says, not on a badge.
9. Your rights
If you are in the European Union or the United Kingdom, data protection law gives you the right to ask what we hold about you, to get a copy, to have mistakes corrected, to have your data deleted (subject to section 6), to restrict or object to processing, and to complain to your national data protection authority.
We apply these rights to everyone, wherever you are, because distinguishing would cost more than honouring them. Write to the address below; we will respond within 30 days.
If you think we have handled your data badly, you can complain to the Czech data protection authority -- Urad pro ochranu osobnich udaju, uoou.cz -- or to the supervisory authority where you live. We would rather you wrote to us first, but that is your choice and not a precondition.
Our legal basis for holding account and run records is the performance of the contract between us. Our basis for the ledger and for service logs is our legitimate interest in a verification service whose results are defensible and whose faults are findable.
10. Contact
Everything -- questions, access requests, deletion, complaints -- goes to support@dualquant.ai. There is no separate privacy desk; the people who built the system answer the mail.
See also the white paper and the Terms of Service.
This service is offered by DualQuant. Verification is performed by DualQuant alone; no broker, exchange, data vendor or fund has any stake in a verdict.