QUANT_API
UTCSign inGet a key ↗
SECURITY

What we actually do.
Nothing we don’t.

This page exists for procurement and security reviews. Every claim below describes a control that exists in our codebase today — no aspirational language, no checkbox theater. Where we don’t have something (yet), we say so.

ACCOUNT & ACCESS
TLS everywhere

The website, dashboard and API are served exclusively over TLS. Session cookies are flagged Secure in production, so they are never sent over plaintext connections.

Passwords: PBKDF2-SHA256, 600,000 iterations

Passwords are hashed with PBKDF2-HMAC-SHA256 at 600,000 iterations with a per-user random salt. Only the hash is stored — never the password. Verification uses constant-time comparison.

Optional TOTP two-factor authentication

Any account can enable RFC-6238 TOTP (Google Authenticator and compatible apps). 2FA attempts are capped per account — not just per IP — so distributed code-guessing is throttled too.

HMAC-signed sessions in HttpOnly cookies

Dashboard sessions are HMAC-SHA256-signed tokens delivered in an HttpOnly, Secure, SameSite cookie — unreadable from page JavaScript. Each user carries a session epoch: changing your password bumps it and instantly revokes every outstanding session, everywhere.

API keys are hashed; the secret is shown once

We store only the SHA-256 hash of each API key — the full secret is displayed exactly once, at creation, and cannot be retrieved afterwards (not even by us). Keys are individually revocable from the dashboard.

Rate limits on every public surface

Signup, login, password reset and the other unauthenticated endpoints are rate-limited and answer 429 under abuse. Email-sending paths (verification, reset) are throttled to prevent enumeration and spam.

PLATFORM & DATA INTEGRITY
Watermarked exports with an audit manifest

Every dataset export is tagged with a unique watermark ID, and a manifest of the export — what was exported, by whom, under which accepted terms — is persisted for audit. Leaked files are traceable to the account that produced them.

Payments: Stripe, signed webhooks, idempotent processing

Billing runs on Stripe Checkout — card data goes to Stripe and never reaches our servers. Incoming webhooks are verified against the Stripe signature, and each event is processed idempotently: the idempotency record and the account change commit in a single transaction, so replayed events cannot double-apply.

Separated data plane — the API only reads

Feature values are computed on a separate data plane and pushed to the serving store through an internal endpoint gated by a dedicated shared-secret token that fails closed if unconfigured. No customer credential — API key or session — can write market data. The customer-facing API only reads feature points.

Point-in-time discipline as an integrity property

Every read enforces ts ≤ as_of: the API cannot return data from after your requested timestamp. This is the product guarantee, but it is also an integrity control — responses are reproducible and auditable against the stored series.

CERTIFICATIONS

No SOC 2. No ISO 27001. Not yet.

We hold no third-party security certifications today, and we won’t pretend otherwise — you will not find a borrowed badge wall here. We are a small team, and the controls above are what we have actually built. If your procurement process requires a formal attestation or a security questionnaire, ask us about our roadmap — we answer questionnaires directly and honestly.

We also make no data-residency claims on this page: if where the data lives matters for your mandate, ask and we’ll tell you precisely what we can — and can’t — commit to.

sales@quant-api.dev
FOUND A VULNERABILITY?

Report it to sales@quant-api.devwith “Security disclosure” in the subject — it reaches the engineers who run the platform. We read every report and reply to genuine findings.

RUNNING A REVIEW?

Evaluating us for a fund or desk? See /enterprise for custom plans and contract terms, or start with the API docs — every account begins with a 14-day free trial, no card.