Service profileArt. 28(3) register of information
What service does Qalypto provide, in register-of-information terms?
Provision of market data (crypto perpetual futures): real-time delivery and historical retrieval of trade, order-book, ticker, kline and liquidation data from Binance, Bybit, OKX and Bitget, with cryptographic integrity proofs and ESMA-format compliance exports. Qalypto is a data vendor, it does not execute orders, hold client assets or make regulatory filings.
Service profileArt. 28 proportionality
Does the service support a critical or important function of the client?
That classification is the client's to make. Typical use, record-keeping evidence and surveillance input, is important but not in the real-time execution path of client trading. Market data delivered by Qalypto remains fully retrievable from history after an outage, so a temporary loss of the live feed does not destroy the record.
Service profiledue diligence
Where does the service run and where is the data stored?
Primary infrastructure is a dedicated bare-metal server operated by Hetzner Online GmbH in Germany, running K3s (Kubernetes), ClickHouse, Kafka and Redis. Backups are stored off-site with a second, independent provider (Cloudflare R2 object storage). The public website runs on Vercel and serves no market data.
Service profiledue diligence
Does Qalypto hold certifications such as ISO 27001 or SOC 2?
No. Qalypto is an early-stage vendor and does not yet hold formal certifications. The compensating model is verification instead of attestation: integrity, completeness, incident history and backup health are published continuously on the trust page, and the cryptographic proofs can be recomputed by anyone with the open-source verifier, offline, without trusting Qalypto. A due-diligence reviewer can check the controls directly rather than reading an auditor's summary of them.
ICT risk managementArt. 5-6 governance
How is ICT risk management organised?
Qalypto operates a small, fully automated estate: every ingestion pipeline, quality gate, seal job and backup is code in one repository, deployed as containers with pinned images. Risk controls are executable checks rather than policy documents: data-quality gates run continuously, the nightly seal refuses to certify a day that fails its content checks, and backup restore tests run automatically. Operational documentation and runbooks are maintained alongside the code.
ICT risk managementArt. 8 identification
Is there an inventory of ICT assets and dependencies?
Yes. The full stack is declared in versioned Kubernetes manifests and Dockerfiles in the repository: every service, its image, its configuration and its dependencies. There is no undocumented infrastructure; anything not in the manifests does not run.
ICT risk managementArt. 9 protection
How are changes to production controlled?
All changes go through code: container images are rebuilt from the repository and rolled out via Kubernetes. The compliance API image embeds its own acceptance test, an image that would emit schema-invalid ESMA documents fails at build time and cannot be deployed. Sealed proof data is append-only by design; a revision to a sealed day is recorded as a new revision, never an overwrite.
ICT risk managementArt. 24-27 testing
What resilience testing is performed?
Automated and continuous: backup restore tests run on schedule against real backups and publish their result to the public trust page; data-quality checks (duplicates, phantom trades, sequence continuity, kline parity against venue REST APIs, crossed books) run around the clock; the notary service has performed over 14 million independent verifications of stored candles against the venues' own records. External penetration testing has not yet been commissioned and is stated here honestly rather than claimed.
Data integrityArt. 9(1) integrity of data
How does Qalypto prove that delivered data is complete and unaltered?
Every UTC day is sealed into a single Merkle super-root (RFC 6962 construction) over every stored row, timestamped with RFC 3161 and anchored in Bitcoin via OpenTimestamps. The per-day registry entries are published append-only to off-site object storage. Changing a single field in history would change the root and break the anchor. As of July 2026 more than 190 consecutive days covering roughly 7 billion rows are sealed and Bitcoin-anchored.
Data integrityverification
Can we verify the data without relying on Qalypto?
Yes, that is the design goal. The verifier is open source (MIT, Python and JavaScript, standard library only, github.com/Qalypto/verifier) and recomputes cell roots, day super-roots, single-row inclusion proofs and the Bitcoin anchor entirely offline. It is also bundled inside every case dossier, so the evidence package verifies itself even if Qalypto no longer exists.
Data integrityprovenance
Is the original source material retained?
Yes. Raw WebSocket frames are archived with nanosecond receive timestamps before any parsing, and the raw archives are included in the daily seal. Normalised rows carry provenance columns recording when each message was produced, transported and stored, with honest NULLs where a venue does not supply a field.
Data integrityindependent checks
Is data quality checked against independent references?
Yes. A notary service continuously re-fetches final candles from the venues' official REST APIs and compares them with what was stored from the live stream; parity and continuity checks run per venue and per instrument. Results, including failures, are public on the trust page.
Data integrityauditability
Are deliveries to us auditable after the fact?
Every data delivery served by the compliance API (exports, dossiers, proofs, best-execution snapshots) is logged with client identity, endpoint, parameters, timestamp and the SHA-256 hash of the exact content delivered; dossier hashes are computed over the actual ZIP file. Denied requests (bad or revoked keys) are logged as well. A client can therefore prove afterwards precisely what was received and when.
Availability & recoveryArt. 12 backup
What is the backup regime?
Nightly incremental backups and rolling full backups of the entire ClickHouse dataset to off-site object storage at a second provider. A monthly full snapshot is retained under a write-once (object-locked) prefix; the rolling backups are not object-locked, their tamper evidence comes from the proof layer instead: a restored dataset is re-verifiable against the public Merkle registry and the Bitcoin anchors, so a modified backup cannot pass verification. Backup age and size are monitored continuously and shown publicly on the trust page.
Availability & recoveryArt. 12 restoration
Are restores actually tested?
Yes, automatically and on schedule: a restore test job regularly restores from the real off-site backups and verifies the result, and the time since the last successful restore test is published on the trust page. A backup that has never been restored is treated as no backup.
Availability & recoveryRPO / RTO
What recovery point and recovery time can we assume?
Recovery point: up to 24 hours for a full loss of the primary server (nightly incremental cadence). Recovery time: restore from the off-site backups is scripted and exercised automatically inside the cluster; a full rebuild onto replacement hardware follows the same scripted path but has not yet been rehearsed end to end, and Qalypto does not currently contract a hard RTO. Live-stream data missed during an outage of the primary is a real gap and is disclosed as such in the incident ledger rather than papered over.
Availability & recoverymonitoring
How is availability monitored?
A watchdog checks the freshness of every continuous venue and channel stream (4 venues times trade, orderbook, ticker, kline) every few minutes and escalates by email when a stream dies or thins out against its own baseline; the event-driven liquidation channel is checked for presence over a longer window, since silence there can be genuine. Independent cron jobs verify data quality, seal health and backup health. Monitoring checks and their latest results are visible on the public trust page, the same view Qalypto operates from.
Availability & recoverysingle points of failure
Is the primary infrastructure redundant?
Honest answer: the primary database runs on one dedicated bare-metal server. Mitigations are layered around that fact: durable Kafka transport decouples ingestion, WORM off-site backups with tested restores bound data loss, and the proof registry lives off-site. Multi-node redundancy is on the roadmap; it is not claimed as present today.
Incidents & transparencyArt. 17-19 incident management
How are ICT incidents detected, handled and communicated?
Detection is automated (watchdog freshness checks, quality gates, seal health, backup monitors) with email escalation to the operator. Every data gap is recorded in a machine-readable incident ledger with start, end, cause and backfill status, published on the trust page. Clients materially affected by an incident are notified directly. Qalypto's incident disclosure is public by default, a reviewer can read the complete gap history of the last 30 days at any time.
Incidents & transparencyArt. 19 reporting support
Will Qalypto support our own incident reporting duties?
Yes. The incident ledger, quality-check history and proof registry give exact, timestamped evidence of what happened and what data was affected, which a client can attach to its own DORA incident report. Case dossiers can be generated for any affected window.
Incidents & transparencytrack record
What is the incident track record?
The public ledger discloses every gap since monitoring began, including cause (venue outage, resync, own maintenance) and whether the data was backfilled or is unrecoverable. There are no undisclosed classes of incident: if the ledger and quality checks are green, that is the same signal Qalypto itself operates on.
Incidents & transparencyno silent repair
Can incidents be silently repaired after the fact?
No. Sealed days are append-only; a backfill or repair of an already sealed day produces a new, logged revision whose registry entry sits next to the original. The proof chain makes silent history rewriting detectable by any client running the verifier.
Access & securityArt. 9(4) access control
How is client access to data controlled?
Three separate access paths, each with its own credential: direct SQL access uses per-client ClickHouse users with row-level policies limited to entitled tables; the real-time WebSocket feed authenticates via Cloudflare Access service tokens; the compliance API uses per-client API keys. There are no shared credentials between clients.
Access & securitycredential handling
How are API credentials stored and revoked?
Compliance API keys are stored as SHA-256 hashes only, never in plaintext; the full key is shown exactly once at creation. Revocation is a single switch and takes effect within at most 60 seconds (fail-closed cache). Failed and revoked-key attempts are logged with an audit trail.
Access & securityencryption
Is data encrypted in transit and at rest?
In transit: TLS on every client-facing path (HTTPS, secure WebSocket, ClickHouse native TLS). At rest: off-site backups are stored on encrypted object storage (provider-side encryption, with a write-once prefix for the monthly full snapshot); the primary server is a physically dedicated machine in a Hetzner data centre, not shared tenancy. Full-disk encryption on the primary is not currently claimed.
Access & securityhardening
How are the services themselves hardened?
Containers run from minimal images as non-root users; the compliance API runs with a read-only root filesystem; internal services are not exposed publicly and client-facing endpoints pass through Cloudflare. The Kubernetes cluster is single-purpose and runs no third-party workloads.
Access & securitypersonal data
What personal data does Qalypto process?
Almost none. Market data is public-origin exchange data and contains no personal data. Client-side, Qalypto holds business contact details and billing data processed via Stripe. Portal login credentials are stored bcrypt-hashed and compliance API keys as SHA-256 hashes only; database access credentials issued to a client are retained in the provisioning system so onboarding material can be re-issued. There is no personal data of the client's end customers in the pipeline.
Subcontractors & concentrationArt. 28-30 subcontracting
Which subcontractors and sub-providers does the service rely on?
Hetzner Online GmbH (Germany): primary hosting. Cloudflare: network edge, tunnel and R2 backup object storage. Vercel: website hosting, no market data. Stripe: billing. Resend: transactional alert email. GitHub: source code and container registry. No other party touches the data path, and no subcontractor can alter stored market data without breaking the public proof chain.
Subcontractors & concentrationArt. 29 concentration risk
How is provider concentration risk addressed?
Hosting and backup storage are deliberately at two independent providers, so no single provider failure can destroy both the live system and its backups. The proof registry is additionally public and Bitcoin-anchored, so even total loss of both providers would not invalidate already delivered evidence. Dependence on the four data venues themselves is inherent to the product and is mitigated by archiving the raw frames as received.
Subcontractors & concentrationoversight
Can we audit or inspect the service?
The strongest audit is available continuously and without an appointment: the trust page exposes live quality checks, incident history, backup health and the complete proof registry, and the verifier recomputes the evidence chain offline. Contractual audit and information rights for regulated clients are agreed in the service agreement, including responses to written due-diligence questionnaires beyond this catalogue.
Exit & portabilityArt. 28(8) exit strategy
What happens if we terminate, or if Qalypto shuts down?
Data is delivered in open formats throughout the relationship (SQL access, CSV export, ZIP dossiers), so there is no terminal export cliff: a client that mirrors its entitled data continuously already holds everything. Evidence remains valid after exit because verification does not depend on Qalypto: the verifier is MIT-licensed and public, registry entries are published off-site, and the Bitcoin anchors exist independently of any Qalypto system.
Exit & portabilityportability
In what formats can we take our data out?
Direct SQL over the ClickHouse interface (any format ClickHouse emits, including CSV, TSV, Parquet and JSON), REST exports from the compliance API (ESMA ISO-20022 XML, CSV, ZIP dossiers), and the per-day proof artifacts as JSON. No proprietary formats are used anywhere in the delivery path.
Exit & portabilityretention
How long is data retained?
Market data and proof artifacts are retained without scheduled deletion; the dataset is append-only and history is the product. The client-facing retention and recovery policy states channel-by-channel start dates honestly, including channels that began later than others, so retention claims can be checked against the sealed record.
This catalogue is maintained alongside the systems it describes and reflects the state of July 2026. It supports, but does not replace, the client's own risk assessment under DORA. For contractual commitments, signed questionnaires or the security whitepaper, contact info@qalypto.com.
