QANTERION Security and Account Control

Last reviewed: 2026-08-09 · Owner: QANTERION engineering, [email protected]

This page describes controls that exist in the product today. It deliberately contains no security certification, no “bank-grade” or “military-grade” language, and no claim we cannot point at code for. Where a control is not implemented, it says so.

The custody model, stated plainly

QANTERION is not a non-custodial product. Any page or third-party summary describing it as non-custodial is wrong.

QANTERION maintains customer balances on its own double-entry ledger. When real-money funding is enabled, funds are held under Qanterion LLC’s arrangements with its payment and custody providers. You are not holding those funds in a wallet only you control, and you should not assume otherwise.

What is true, and is enforced rather than promised:

  • Real-money funding is off by default. Real-money trading enablement is an explicit, per-account step: deposits and withdrawals require live funding to be explicitly enabled and payment and custody providers to be configured. In paper funding mode, no payment or custody provider is contacted at all; the request is refused.
  • Live trading is off by default. Strategy commands that would touch a live book are refused unless live trading is explicitly enabled with a broker and market-data provider configured.
  • Simulation and live are separated at the account level, not by a UI toggle. Simulated and live activity resolve to different tenant scopes at the strategy execution core.

Exchange API keys

QANTERION does not ask for, receive, or store your exchange API keys. There is no exchange-credential store in the product.

This is worth stating because the category norm is the opposite. Most “trading bot” products ask you to paste an exchange API key with trade permissions. QANTERION’s architecture does not involve one, so the usual questions about read/trade/cancel/transfer/withdrawal permission scopes on a third-party key do not apply here. There is no key of yours to scope, leak, or revoke.

Credentials to the strategy execution core are held server-side only. Browser and native clients never hold them.

Account access

Implemented today:

  • Passkeys (WebAuthn) as a sign-in method.
  • Time-based one-time passwords (TOTP) as a second factor.
  • Single-use recovery codes for account recovery.
  • Email verification on registration and password reset via expiring single-use tokens.
  • Google sign-in as an alternative identity provider.
  • Per-session records and a login-event history, so sign-ins are attributable rather than anonymous.

Secrets held server-side are encrypted at rest through a dedicated sealed-secret module rather than stored in plaintext columns.

Withdrawal controls

Withdrawals are the highest-consequence operation in the product and carry the most control:

  • Address whitelist with a cooling period. A withdrawal destination must be registered before use and sits in a pending state for a configured cooling window before it becomes usable. Registered addresses are stored encrypted, with a separate mask for display and a hash for matching. The full address is not held in plaintext.
  • Dual approval (maker–checker). A withdrawal request records a distinct maker and checker; the request cannot be self-approved by a single actor.
  • Recorded approval decisions. Every approval or rejection is stored with the deciding actor and a timestamp, giving an auditable decision trail rather than a final status alone.
  • Idempotency. Money-moving requests are keyed so that a retried or replayed request does not produce a second movement.

Administrative controls

  • Dual control on sensitive administrative operations, with the same maker–checker split, an explicitly authorized scope, and a domain revision the executing side re-checks independently before acting.
  • Administrative sign-in requires a second factor.
  • A kill switch exists as a first-class, recorded operation for halting activity.
  • Durable audit and outbox events record state changes rather than relying on application logs alone.
  • Reconciliation runs compare recorded financial state against providers rather than trusting a single side.

Integration failure behavior

When the strategy execution core cannot be reached, the platform fails closed. Strategy commands are rejected with an explicit error. The platform does not generate synthetic fills to keep the interface populated; at most it briefly serves the last successfully retrieved activity, and it filters activity to the current run so a previous run’s trades cannot appear as this one’s.

A platform-side acknowledgement is not an execution. A command is only treated as executed once the strategy execution core confirms it.

Website and analytics

  • The marketing site is a static build served with a strict Content-Security-Policy generated at build time from the exact set of scripts that shipped.
  • First-party visitor analytics is off unless explicitly enabled. When enabled, the site records anonymous pageviews and CTA events to the same-origin collector.
  • Portfolio data, strategy contents, credentials, and payment details are never sent to marketing analytics.

Data retention and deletion

Retention periods, deletion requests, and the categories of data held are governed by the Privacy Policy. We are not restating them here in different words, because two descriptions of the same policy is how they drift apart. The mechanics of closing an account are documented separately in Account Deletion.

Reporting a vulnerability

Send it to [email protected] with enough detail to reproduce. There is no bug-bounty program at this time; we would rather say that than imply one exists.

Known limitations

Stated because omitting them would make this page less useful, not more:

  • There is no published third-party security audit or penetration-test report.
  • There is no security certification (SOC 2, ISO 27001, or otherwise), and none is claimed.
  • There is no bug-bounty program.
  • No named security owner is published. The contact address above is the accountable route.
  • Controls described here cover QANTERION’s own platform. The strategy execution core is a separate system; see backtesting methodology for that boundary.