KuantTrade

Security architecture

Your account stays at your broker. Trading access stays inside defined boundaries.

KuantTrade cannot withdraw or transfer your assets. Because trading access is still financially sensitive, credentials, approvals and automated actions are isolated, constrained and recorded.

  • Non-custodial
  • No withdrawal or transfer access
  • Live automation requires your activation
  • Broker credentials encrypted per connection
  • Machine access is recorded

The boundary

What KuantTrade can and cannot do

The clearest thing on this page, and the one worth reading first. Anything that varies by broker is on the broker's own page rather than generalised here.

KuantTrade can

  • Read the balances and positions the connected workflow needs
  • Transmit orders through the broker connection you made
  • Run automation you activated
  • Apply the risk and account limits you configured
  • Record proposals, checks, approvals and broker responses

KuantTrade cannot

  • Hold your funds or securities
  • Withdraw or transfer assets
  • Change your broker password or its multi-factor settings
  • Create a new broker API credential
  • Approve an order through an external machine identity
  • Activate live automation through an external machine identity
  • Bypass the account limits that are re-applied on the server

KuantTrade does not require withdrawal or transfer access. Use a trade-only credential, and restrict it by IP where your broker supports allowlisting. Per-broker connection and permission detail

How an order gets out

Nothing reaches a broker without passing through all of it

  1. 01

    Your approval

    A person activates a strategy or confirms an order.

  2. 02

    Activated strategy

    The version you activated, on the account you chose.

  3. 03

    Execution-time checks

    Limits are applied again here, not only when the rule was written.

  4. 04

    Transmission

    The instruction leaves for the venue's own API.

  5. 05

    Your broker

    Where the account, the funds and the execution are.

  • An AI client may read and propose. It cannot approve or activate.
  • A webhook may signal a workflow you already authorised. It cannot change its account or its limits.

There is no withdrawal or asset-transfer path in this diagram, because there is none in the system.

Machine authority

Different machine identities, different authority

Automation means a machine acts. It does not mean one machine identity holds every permission, and the three that exist here are not interchangeable.

External AI client

Reads only the scopes granted to it, and can write a proposal or a draft.

Cannot confirm an order, cannot activate live automation, and cannot mint another machine credential.

Webhook sender

Signals one workflow that was configured and activated in advance, with a secret scoped to that single strategy.

Cannot choose a different account, cannot raise a quantity or a limit, and cannot change the strategy it signals.

Internal execution engine

Acts only under a strategy a person activated, or an order a person confirmed.

Cannot step outside the account limits, and reaches broker credentials only through the service that holds them.

Custody and account boundary

What the platform can never do with your account, and what it can.

No custody, at any time
The company does not take custody of, hold, receive or control funds, securities or digital assets, and cannot withdraw or transfer them. They remain in the account you already hold, in your own name, throughout. There is no omnibus or pooled account anywhere in the path.
Trading access is still financially sensitive
No withdrawal is not the same as no risk. A key that can trade can also open positions you did not intend, close ones you did, work an account down through spread and commission, or repeat an order. Non-custodial is a boundary on what can be taken, not a promise that nothing can be lost.
Revocation stays with you
The credential is one you created at your broker and can delete there, and no request to us is needed for that to take effect: once the broker processes the revocation, requests carrying it stop working. Disconnecting it here is the other half, and invalidates the local cache straight away.

Broker credentials

One code path, one format, and a plaintext lifetime measured in the moment an order takes.

Encrypted per connection, bound to the owner
Each broker credential is encrypted with its own AES-256-GCM data key, with the account, the broker and the label as associated data. A ciphertext moved to another account or another broker fails authentication rather than decrypting into the wrong context.
A single code path, and no fallback
Every read and write goes through one module supporting exactly one envelope version. The earlier format was migrated out rather than kept for compatibility, and anything else raises rather than degrading, because a fallback path is how a retired scheme survives its retirement.
Decrypted for the order, not for the session
A credential is decrypted at the moment an order is placed and held for the shortest period the operation needs. It is not persisted anywhere in decrypted form, it is not written to logs, and the cache entry is invalidated on expiry, on disconnection and when the session generation moves. It is never read from a configuration file or an environment variable, including by test and diagnostic code.

Key management

What wraps the data keys, where it lives, and what can reach it.

A per-user wrapping key that cannot be exported
Created non-exportable in HashiCorp Vault Transit: the key material cannot be read out, only used to wrap and unwrap, and each user's credentials are wrapped under their own. Access to those operations is policy-bound, authenticated and recorded, which is the accurate claim. A page that says no operator could ever reach a cryptographic operation is describing an organisation rather than a system.
The keys that open the vault are not in the cluster
The vault unseals against a second vault rather than a file or a cluster secret, so a restart recovers without a human and without leaving unseal material beside the workload. Initialisation is performed outside the cluster and those keys are held off it.
The decrypting workload holds no root token
It authenticates with its own role and is scoped to one user's key paths, so it can use the wrapping keys and cannot enumerate or export them. There is no static or root token in its deployment to borrow.
The vault's own configuration is code
Mounts, keys, roles and policies are declared as infrastructure rather than clicked into a console, so what a reviewer reads is what is deployed and a change to it is a diff.

Identity and sensitive actions

What the browser holds, and what stops working when a session ends.

Bearer tokens are not exposed to page scripts
Authentication runs through a backend-for-frontend, the browser holds an HttpOnly, Secure, SameSite cookie, and the authorisation flow uses PKCE. HttpOnly reduces the risk of a browser script stealing a token; it does not stop a script from attempting actions inside a live session, which is a separate problem addressed by the same-site restriction and by the response headers below.
Ending a session ends decryption
Every cached unwrap carries the session generation it was made under. When that generation moves the cached key is stale and the decrypt is refused rather than served from memory, so revocation reaches memory and not only the database.
Two permissions no external machine identity can hold
Confirming an order and activating a strategy are the two that commit funds. The issuing API subtracts them from what it can mint, and the request path refuses them to any machine caller regardless of its stored record. Two independent mechanisms, kept separate on purpose. A machine credential also cannot mint another one.

Automation and execution safety

A valid signal is not permission to bypass the checks.

The ceiling is applied again at confirmation
A proposal is checked when it is written and checked again when it is confirmed, because the account moved in between. A proposal can also come back allowed with some bounds unassessed, most often when the instrument cannot be priced at that instant, and it says which ones rather than implying everything passed.
Over the limit is refused, not quietly reduced
A request past a ceiling comes back rejected with both numbers shown. It is not clamped down to the largest legal size and sent, which would be an order nobody asked for arriving under your name.
The stop for autonomous action fails closed
If the state that holds the stop switch cannot be read, the agent path treats it as engaged and submits nothing. A stop button that fails to stop is not a stop button. The entry gate for a strategy a person already approved is deliberately the other way around, and the difference is written into the code rather than left to chance.
A signal cannot widen its own authority
The secret is scoped to one strategy rather than to an account, so a leak is one strategy's problem and can be rotated on its own. A secret in the URL is refused outright, and a body that disagrees with the address is refused rather than reconciled.

Data and network security

What leaves a machine, and what the browser is told to insist on.

External connections are TLS
This site, the application and every broker endpoint are reached over TLS. A broker that publishes an API is called directly at that published host rather than through anything of ours standing in front of it. One broker on our Brokers page is the exception, and the reason is its own model: it only allows access to your account through gateway software it distributes, its Client Portal Gateway. We run that software in a container dedicated to you, and calls to that broker go there. Its login screen is served to your browser through our host, so your login details for that broker pass through our server on the way to your container; they are not written to our logs. The broker generates the gateway's certificate and it has expired, so certificate verification is not possible on that one hop; the broker's public hosts are always verified.
This site sends transport and content headers
Strict transport security for a year including subdomains, content-type sniffing off, referrers trimmed on cross-origin navigation, and camera, microphone and location denied by policy because nothing here asks for them. Framing is refused in both the current and the legacy header.
The content policy is scoped, and says so
It covers framing, the base URI, form targets and plugin content. It is not a script policy, and calling it one would be the kind of claim this page exists to avoid: a script policy done properly needs a per-request nonce, and one copied without that either breaks the page or permits inline script and calls itself protection.

Tenant isolation

Enforced by the shape of the interface rather than by review.

A tool cannot ask which account to read
Identity is injected from the authenticated principal and no tool may declare an argument naming one. Nine spellings and abbreviations are refused, because a check that only catches the exact string somebody thought of first is not a check. The rule runs when the module loads and a violation stops the process from starting.
Out of schema is refused, not adjusted
Argument models reject fields they do not declare, so a caller cannot believe it constrained a call that ran unconstrained, and a value past a limit comes back rejected with both numbers rather than clamped to the largest legal one.

Audit and retention

What is written down, by whom, and for how long.

The chain is recorded as it happens
Proposal, checks, approval, the request made to the broker and the answer it gave, written by the service rather than by whichever screen someone had open. A trail produced by a client is a trail that stops when the client does.
An approval names exactly what it approved
The token binds to a hash of the draft, prefixed so a consent to run a strategy can never equal a consent to place a single order, with the kind recorded separately as a second check.
Machine access is a durable record
Which client connected, when, and what it requested is persisted rather than inferred from logs, so a question about a machine identity has an answer that outlives a log rotation.
Retention is published per category
The periods are stated category by category in the Privacy Policy rather than summarised differently here, because two texts about one retention schedule drift apart at the speed of whichever one somebody remembers to edit.

Vulnerability reporting

How a finder reaches us without having to guess.

A published address, in the standard place
The file at /.well-known/security.txt names the contact, the canonical location and the languages we read, in the format a researcher expects to find it in. Reports are read in English and Turkish.
What a report needs, and where to stop
The finding, how to reproduce it, and the time window it was observed in. Please do not access another person's account or data, and stop at the point where a proof would require going further.

For security reviewers

Where the detail lives

This page states the boundary. Configuration and per-venue detail belong with the thing being configured, so they are linked rather than repeated.