Security & Compliance

Hosting & infrastructure

• Region. The service runs on dedicated servers in the EU (Germany).
• Edge. Cloudflare sits in front of every public endpoint, providing TLS termination, DDoS mitigation, and a web application firewall.
• Transport. All traffic is served over HTTPS (TLS 1.2+); plaintext HTTP is redirected to HTTPS.

Service topology

The platform is not a single box. Public API traffic is load-balanced across multiple dedicated API nodes; nodes join the pool only once they pass a readiness probe, and a node that cannot serve correctly is held out of rotation rather than answering. Distinct hosts carry distinct responsibilities:

• API nodes - serve the live REST surface. One node is designated primary and additionally runs the shared writers, nightly processors, and monitoring; the others run read-only and are gated by configuration from touching shared-state writes.
• Historical archive - a separate host and time-series store for point-in-time replay, isolated from live serving so a backtest sweep cannot degrade the live path.
• Market-data ingest - a dedicated host consuming the upstream feeds and publishing to the API fleet over a private network.
• Probing - an off-fleet monitor exercises the real public request path every 30 seconds, so availability is measured independently of the systems being measured.

Dedicated and reserved-capacity deployments for a single client are scoped under the commercial tiers; see commercial enquiry.

Data we hold - and don't

• Account data. Email, a hashed password (ASP.NET Identity), an API key, and request/usage logs.
• Billing. Payments are processed by Stripe; we store only Stripe references (customer and subscription IDs). No card data touches our servers - cardholder data is handled entirely by Stripe (PCI DSS Level 1).
• Product data. FlashAlpha is a computed-analytics layer over the public US listed-options market. We do not hold customer trading positions, portfolios, order flow, or brokerage credentials.

Encryption & access

• In transit. TLS 1.2+ end-to-end (Cloudflare edge and origin).
• At rest. Application and market data reside on access-controlled servers in EU data centres; database credentials are injected from host-local secrets and are not embedded in client-facing code.
• Authentication. REST access uses a per-account X-Api-Key; the MCP server additionally supports OAuth 2.1 (PKCE + dynamic client registration). Administrative surfaces are separately authenticated.
• Access control & abuse. Per-user daily request quotas (HTTP 429 + Retry-After on exhaustion) and tiered entitlements gate what each key can read.

Availability & resilience

• Transparency. A public system status page reports live component status and 90-day uptime - API, market-data feed, and historical service - measured by an independent external monitor over the real request path, so a genuine outage is recorded even when a service cannot self-report. The API probe asserts on the response body, not just the status code, so "200 with broken data" counts as down.
• Backups & recovery. Application and market databases are backed up daily on an automated schedule, with copies pulled off the production host to separate storage and a restored standby copy maintained as the recovery path. Retention is seven daily generations plus a monthly point. The historical time-series archive is snapshotted daily using the engine's own checkpoint mechanism, so the copy is consistent rather than a hot file copy. Backup jobs alert on any failure.
• Data-quality monitoring. Independent monitors reconcile the data we serve against exchange sources through the session, and correctness-critical endpoints fail closed rather than serve a stale value. The full control set, including its stated limits, is documented at Data Quality & Monitoring and in the methodology whitepaper.
• SLA. Standard tiers are best-effort; a contractual uptime SLA is available under Enterprise agreements.

Data provenance

• Freshness is carried in the response, per feed. Every successful response includes data_as_of: a fixed object reporting when each upstream feed last delivered to the node that answered. Equity and index spot, their option chains, futures and futures options, the classified trade tape, settled open interest and the macro series are reported separately, because they arrive over different pipes and fail independently. A caller does not have to infer freshness from a single timestamp, or ask us whether a feed was lagging at a particular moment - the response states it.
• Historical responses state the vintage of what was replayed. A request to the historical service carries archive_as_of: the vintage of the archive rows actually served for the timestamp requested. This is what makes an archive gap detectable. Ask for 15:59 on a day with no row at 15:59 and the query returns the most recent earlier row; the two responses are otherwise identical, and only this field distinguishes them. Point-in-time work can drop or flag the affected observations rather than consuming them silently.
• Machine-readable and continuous. Both fields are present on every call and are stable in shape, so a client can assert on them in code. Provenance is verifiable by the customer on an ongoing basis rather than asserted once in a document. Endpoints that return a bare JSON array carry the same information in the X-Data-As-Of and X-Endpoint-Version response headers.
• What it does not evidence. A feed timestamp shows that the feed delivered recently. It is not a claim that every contract in a chain is equally current - an illiquid strike may not have quoted for hours while its feed is healthy - and it is not a data-accuracy guarantee. Each feed should be read against its own cadence: settled open interest dated to the previous session's close is correct by construction, while an options feed an hour behind during the regular session is not. The full definition is in the API reference and the methodology whitepaper.

Support & escalation

• Channels. [email protected] for technical issues, [email protected] for commercial and contractual matters. Commercial enquiries are answered within one business day.
• Who answers. Support is handled directly by the engineering team that builds and operates the platform. There is no first-line script tier: a data or methodology question reaches the person who wrote the calculation.
• Incident handling. Automated monitors alert the operations owner by email with escalation on repeat failure; incidents affecting the public request path are reflected on the status page. Named escalation contacts, response-time commitments, and a shared incident channel are scoped under commercial agreements.
• Change communication. API changes are published in the changelog; methodology changes are versioned in the whitepaper at a stable URL so citations survive revisions.

Company

• Legal entity. FlashAlpha LTD, registered in Cyprus (EU). Contracting, invoicing, and licensing are with that entity.
• Commercial terms. Standard plans are card-billed through Stripe. Commercial and Enterprise agreements support annual invoicing by bank transfer, and master service agreements, data-processing terms, and SLA riders are handled as part of scoping - see commercial enquiry.
• Key-person concentration. FlashAlpha is a small, founder-led engineering team. That is why response times are short and bespoke work ships quickly; it also means continuity terms (source escrow, extended notice, transition assistance) are a fair question, and we scope them under Enterprise agreements rather than pretend the question does not apply.

Privacy & compliance

• GDPR. Data is EU-hosted and handled in line with GDPR principles; data-processing terms and formal data-residency commitments are available under Enterprise agreements. See Privacy, Terms, and Risk disclosure.
• Current attestation status. FlashAlpha is not currently SOC 2 or ISO 27001 certified. We state that plainly rather than imply a certification we do not hold. Formal attestations, security questionnaires, and data-residency guarantees are handled as Enterprise-scoped engagements.

Subprocessors

The third parties involved in operating the service:

• Hosting - EU dedicated-server provider (Hetzner, Germany).
• Cloudflare - CDN, TLS, DDoS/WAF at the edge.
• Stripe - billing and payment processing.
• Email provider - account and transactional email.
• Upstream market-data providers - market data only; no customer data is shared with them.

This overview describes the current operational posture and is updated as that posture changes; it is not a contract. Enterprise commitments are set out in the applicable agreement.