TW Market DataTrust Center

Trust, by construction.

Data security is the foundation of our product. From source to transport to governance, the controls at every layer are enforced by the architecture itself, and they stand up to enterprise-grade security review.

We hold no third-party certification — no SOC 2, no ISO 27001. What is below is what we can show: signed evidence you can download, a self-assessment with its gaps named, and a regulatory mapping that states what it does not claim.

Overview

Point-in-time by construction: every disclosure row carries the date the market could first have known it, so a backtest filtered on that column cannot see a number before it existed. Coverage gaps are reported rather than filled in.

Read the detail →

Standards & Frameworks

Open standards and tools this is built on. Implemented by us — not certifications, and not endorsements by the projects named.

OpenSSF
CycloneDX
OWASP
Sigstore
SLSA
IETF
IETF

Documents

Bulk download (4 public)

Reports

Software Bill of Materials

Legal

Subprocessors
Personal data
No. The holding data from TDCC is an aggregated distribution across holder bands, not the identity of any individual holder.
Material non-public information
No. Every series originates in official public disclosure. There is no insider-sourced and no expert-network component anywhere in the catalogue.

Product Security

Least-privilege internal access
Least privilege, with the read-only monitoring role separated from the application credential so that observability does not carry write access.
Per-key entitlement, resolved per request
Signed data checkpoints (ed25519 Merkle)
Yes. Each published snapshot commits to a cryptographically signed Merkle checkpoint, exposed through four public proof endpoints, and verified by a standard-library script the buyer runs themselves. The honest boundary: it proves integrity and origin, not semantic correctness, and it is not a proof of when a computation occurred.
Audit logging — not tamper-evident
Every request is recorded, but the database user that writes those rows can also alter them (ASVS V7.2).

Data Security

Encryption in transit
TLS, graded A+ by Qualys SSL Labs across four endpoints: HSTS enabled, TLS 1.2 and 1.3 only, 1.0 and 1.1 refused, no RC4, forward secrecy throughout. Anyone can re-run that test against us.
Daily off-site backups
Daily encrypted off-site backups to Cloudflare R2.
Restore drill, actually performed (2026-08-15)
Yes — a restore drill was performed with the real keys, not a dry run against a dummy archive. It is recorded in the Trust Center updates feed with its date and measured duration.
Archive integrity verified — pg_restore --list, 252 tables (2026-08-27)

App Security

Responsible disclosure
SBOM published
Dependency scanning — weekly, informational (pip-audit, osv-scanner, Dependabot)
Known unpatched dependencies, published
Yes: approximately 16 open dependency CVEs as of 2026-08-19, none in a path that handles customer credentials. The count is published rather than the list — a count cannot be acted on by an attacker, an enumeration can. We would rather disclose an unflattering number than answer this question with a clean one.

Agent / MCP Security

Threat model mapped to the implementation
Tool output is typed and schema-validated
Free text is not sanitised, deliberately
The records carry regulators' and companies' own wording. Rewriting them would destroy what the dataset is for, so the mitigation belongs at the consuming end.

Infrastructure

Hosting
Self-hosted, which keeps data sovereignty with us rather than with a managed platform: compute at Contabo in Japan, with Cloudflare at the edge providing WAF and DDoS protection.
Monitoring
An external status page (Uptime Kuma) plus internal Prometheus and Grafana covering route latency, cron success, data freshness and database health.
Environment separation
Production is separated from preview deployments, with separately scoped credentials. Formal documentation of the boundary is not written.

Business Continuity

Recovery point
Daily snapshots, so the worst case is approximately 24 hours of loss. That is the honest figure, and it is the one that improves when point-in-time recovery lands.
Incident disclosure
On the public status page, named, with cause, impact and a time window — including the periods where no sample was taken. The practice predates this document; the outage write-up is on the page now.
Formal disaster-recovery plan — not written
A restore has been performed and measured; a written plan has not been produced. The drill is evidence, the document is not yet there.

Risk Profile

Data type: Public market disclosures
Personal data: None
Third-party dependence: Yes — hosting, edge/CDN, object storage, email
Recovery point objective: At most 24 hours

What we do not meet

From the ASVS 5.0 Level 2 self-assessment. A mapping that is green all the way down carries no information; these three rows are the ones worth reading.

V14.2Known vulnerabilities not fully remediated

Partial

Dependency scanning is scheduled weekly — pip-audit, osv-scanner and Dependabot — and it is informational: it reports rather than blocking a build. The gap is what it finds. Open dependency CVEs remain, published with their count and date at G2 rather than summarised away, and none sits in a path that handles customer credentials.

V7.2Audit logging is not tamper-evident

Partial

Every request is recorded, but the same database user that writes those rows can also alter them. The Merkle checkpoint machinery already exists and could be extended to cover them; it has not been.

V4.3Two id spaces are both plain strings

Partial

An entitlement check once received a catalog id where it expected a dataset slug. The interface matched, the identifier did not, and it returned 200 — the failure looked entirely normal. It is fixed, but nothing structural prevents the next one: both id spaces are still strings, and the fix is types rather than a patch.

Software bill of materials: 143 components, CycloneDX 1.5.

Standards & Frameworks

Standards we implement or align with, each with what is served today and what is not. These are self-assessed alignments, not certifications, and nobody has audited them. Verified 2026-08-21.

Standard	Status	What is served
Signed Tree Head (STH), §3.2	Served	The sth_envelope on /v2/proof/checkpoints: sth_version=twmd-sth/v1, carrying merkle_root, leaf_count and algo, signed with Ed25519.
Merkle leaf hash with 0x00 prefix, §2.1	Served	sha256(0x00 ‖ canonical_row_bytes), using the same canonicaliser that query_id uses.
Interior node hash with 0x01 prefix, §2.1	Served	sha256(0x01 ‖ left ‖ right). The two prefixes are what stop an interior node being presented as a leaf.
Merkle Audit Path / inclusion proof, §2.1.1	Served	/v2/proof/inclusion, given a dataset and that dataset's row key; every dataset checkpoint carries a real row_key_example.
Log ID / log public key, §4.1	Served	/v2/proof/public-key serves the Ed25519 PEM; each checkpoint names the key it used as signed_by=ed25519:<keyid>.
Odd-node handling (CVE-2012-2459)	Served	An unpaired node is promoted unchanged, never duplicated — duplicating lets two different leaf sets share one root.
Merkle Consistency Proof, §2.1.2	Served	/v2/proof/consistency (proof_version twmd-consistency/v2), given first and second tree sizes. What it proves is that the META-LOG — the log of published tree heads — at size first is a prefix of it at size second: no previously published head was removed, reordered or rewritten.
Scope of that consistency proof	Roadmap	It covers the log of published heads, not each dataset's own tree — those are ordered by row key, which is a different property. The endpoint's own does_not_claim says exactly this.
Timestamp in the STH, §3.2	Served	Deliberately absent. A signature cannot witness its own timing.
Public log, gossip protocol, independent auditors	Roadmap	Not applicable. These are per-dataset snapshot checkpoints, not a public append-only log with third-party auditors.
W3C PROV-O (provenance as JSON-LD)	Served	Served: GET /v2/proof/provenance?dataset=<key> returns W3C PROV-O JSON-LD with no API key. Every entity in the graph carries its own merkle_root and a resolvable verification URL. A dataset with no published checkpoint answers 200 with no graph — and so does a key that does not exist, which the API does not distinguish.
PROV-O on the read endpoints (?format=prov-jsonld)	Roadmap	Not served, and explicitly refused.
C2PA sidecar manifests	Roadmap	Not served.

Regulatory mapping

TWMD is a data and verification layer, not a compliance consultancy. This table says what evidence an institution is handed when it has to satisfy a given sound practice. The obligation stays with the institution; the evidence comes from us.

TWMD's position in this letter first: we are a third-party data provider in the sense of §VII — not an institution that “complies with SR 26-2”. The letter's obligations fall on supervised institutions, so a vendor has nothing to comply with; what we supply is the evidence an institution uses to answer for its data.

The scope boundary, equally first: SR 26-2 governs models, and generative and agentic AI are explicitly outside its scope, left to an institution's existing risk management practices. A product built for agents is therefore outside that scope by the letter's own terms.

A review committee will nonetheless ask data questions with the muscle memory built since SR 11-7 — data suitability, lineage, change management. Datasheets, measured freshness and gap disclosures are ready-made data-suitability documentation.

SR 26-2 stresses proportionality to size and complexity, so this table is most relevant to foreign branches and quantitative funds with Taiwan exposure.

Practice	Status	Evidence / caveat
1. Strategic direction and oversight	Met	A published security facts sheet and self-assessment give the governing body something to cite when it has to state what data its agents use and how far it can be verified.
2. Governance and accountability	Partial	Organisation roles — owner, member, read-only — separating billing from data and reading from credential minting. Keys belong to the organisation and record who created them. The authorisation check fails closed.The roles govern the dashboard and credential handling, not data requests: a key authenticates at the API host carrying no organisation role. Members are added on request; there is no self-service invitation flow.
3. Incorporation of AI risks into the risk management framework	Partial	A Gebru-format datasheet per dataset — composition, cadence, measured freshness, point-in-time semantics, recorded gaps, licence — composed from the registry rather than written per dataset.Thirteen datasets are graded as carrying a backtest trap and their disclosure text is not yet written or published. The datasheet says so explicitly in that case — that a disclosure is required and has not been written — rather than staying silent.
4. Organisational adaptability	Not built	An errata and supersedence mechanism: an error is not erased, it is corrected by a new commitment that supersedes the old one.The design is approved; it is not implemented.
5. Materiality and risk assessment	Met	Per-dataset cadence and measured freshness, with the registry keeping 'has a scheduled producer' separate from 'is inside its own cadence budget'. An assessment needs inputs; these are machine-readable ones.
6. Selection	Met	A public keyless verifier and a self-check page: a buyer can test our claims in their own terminal without having to trust us.
7. Data governance	Met	The main event. Signed Merkle snapshots and an RFC 6962-style meta-log with consistency proofs; as_of point-in-time filtering that prevents look-ahead; and every checkpoint carrying its own does_not_prove statement of what it does not establish.
8. Explainability and transparency	Partial	Citations that resolve to a row, plus a replayable query id — 'which row did this conclusion come from' can be replayed by a machine.Query replay is on the MCP layer; PROV-O format output is not built.
9. Performance management	Met	A leak-resistant benchmark: 148 questions, 40 of them not public on the date asked about. What it demonstrates is pointed — conventional accuracy cannot distinguish an honest agent from one that ignores the time gate; both score 100%, and only leak rate separates them.
10. Human oversight	Met	Sampling only works if the sampled item can be verified. Public proof endpoints and an independent verifier make sampled oversight workable without reading every item by hand.
11. Cyber and ICT risk management	Partial	Data provenance control is the core business: any row resolves to a signed snapshot and a named official source role.The signed MCP tool manifest — the countermeasure to tool poisoning — is published at /v2/proof/tool-manifest with a signature and a surface_hash; measured 2026-08-26, its 34 tools matched the live server's tools/list exactly. Performing the comparison remains the client's step: we publish a manifest that can be checked, we cannot check it on your behalf.
12. Third-party risk management	Partial	We are ourselves the third party this practice governs. Verifiability downgrades 'trust the third party' to 'verify the third party', which is the substantive thing we can offer against it.SLA and DPA templates are still being drafted; wind-down data portability terms are not settled.

Verified 2026-08-21.

Overview

Data integrity

Every figure we return is anchored to a point in time and carries its provenance. That is what makes a backtest defensible and a number auditable months after it was pulled.

Point-in-time integrity
Queries take an as-of date. For datasets that are not point-in-time safe by nature, rows are selected by disclosure date rather than event date, so a query returns what was public at that moment and nothing published after it. Each dataset declares its point-in-time status explicitly.
Coverage and point-in-time status by dataset
Provenance on every response
Responses carry their source role and lineage at the top level: the official upstream, the endpoints involved, the underlying table, and the as-of date of the data itself. A figure can be traced to its origin without a support request.
How the data is collected, normalised and checked
Reproducibility
A point-in-time query is reproducible by construction. A correction published later carries its own disclosure date and therefore surfaces only for as-of dates after it; it does not revise an answer already given. The same query against the same as-of date returns the same rows months later.

Security

The controls below are stated at the level of detail a security questionnaire asks for, and most of them can be confirmed from outside without our involvement.

Encryption in transit, end to end
HTTPS with HSTS at the edge, and the edge connects to origin over TLS with certificate validation enforced — there is no plaintext hop behind the padlock. Every response carries Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy.
Database isolation
Postgres runs on a private container network with no published port, reachable only from the application over internal networking. There is no public listener, and consequently no allow-list to maintain or to misconfigure.
Abuse controls bound to a non-forgeable identity
Sign-in, passkey and device-authorisation endpoints are rate limited per account and per caller. The caller is identified by the connection address supplied by our edge rather than by a client-written forwarding header, so a fabricated header does not obtain a fresh quota.

Reliability

Availability is measured, published including its gaps, and backed by a restore that has actually been performed.

Functional monitoring
The hourly check exercises capabilities rather than probing for a response code: sign-in performs a real session write, update and delete; a dataset is read without a key; the key-issuing service is exercised; and the agent endpoint completes a handshake. A site returning 200 while sign-in is broken is a failure this design detects.
System status
Recorded history
Availability is sampled hourly and published as a record that includes the periods with no sample; those appear as gaps rather than as healthy time. Incidents are published with cause, impact, and a start and end time.
Recorded history and incidents
Backup and recovery
The database is dumped daily to off-site object storage with multi-generation retention. On 2026-08-15 a logical restore from the daily dump completed in 1,816 seconds — approximately 30 minutes. That figure describes a logical restore, not a hot-standby failover. The recovery point is bounded by the backup interval and is therefore at most 24 hours.

Agent governance

What an agent connected to this platform can do is bounded by the interface it is given, not by a policy it is asked to observe.

A read-only interface
The tools we expose list datasets, describe them, query them and find related ones. Every one of them reads. No tool places an order, moves funds or alters a billing state — not disabled by configuration, but absent from the interface.
The full tool list
Human authorisation
Before a CLI or an agent can act on an account, a person approves it in an authenticated browser session. The approval is bound to that session by digest — never the token itself — so it can be attributed afterwards. Approved and denied are terminal states.
The authorisation step
Audit record
Every API call writes a record: the account, the key, the dataset, the endpoint and method, the status code, the latency and the timestamp, joined by a request id. Billing is derived from that ledger rather than counted separately, so the amount charged and the activity recorded cannot diverge.

Subprocessors

Company	Purpose	Location
Cloudflare	CDN, WAF and TLS termination	Global edge
Cloudflare R2	Off-site database backups	Object storage
Contabo	Dedicated server hosting	Japan
Polar	Subscriptions and payment	See their terms
Resend	Transactional email	See their terms
Google	Sign-in (OAuth) and, with consent, analytics	Global

System statusLive and recorded availability, with incident history.Data qualityCoverage, freshness and known limitations per dataset.MethodologyHow the data is collected, normalised and checked.