Regulatory · Annual transparency
The year in numbers. Signed. Anchored.
- Cadence
- Annual · 90 days post fiscal year
- Signed by
- Chief Risk Officer
- Anchoring
- Ethereum + Bitcoin
- Independent audit
- Tier-1 audit firm
Report structure
Seven sections. Every one published.
- 01
Cleared volumes and open interest
Notional cleared by contract class, member tier, and settlement currency. Daily average, peak-day, and year-end open interest. Top-five concentration disclosed at aggregated and contract-class granularity. - 02
Default and near-default events
Any declared default, any event escalating to the default-management playbook, and any near-default event (member distress triggering enhanced monitoring) documented with summary facts and disposition. - 03
Rule changes and governance
Every rulebook amendment adopted in the year — filing date, effective date, public comment summary, and disposition. Governance events (board changes, committee composition) disclosed. - 04
Technology incidents
Every Sev-1 and Sev-2 incident with summary facts, root cause, corrective action, and member impact. Linked back to the public incident-register entry. - 05
Availability and performance
System-class availability versus target, margin back-testing outcomes, stress-testing outcomes, and any Core-Principle-linked performance metrics. - 06
Regulatory engagement
Summary of filings, examinations and enforcement-adjacent engagements with each regulator. No individual member or investigation detail; aggregated activity only. - 07
Forward posture
Planned rulebook changes, planned product expansions, and planned regulatory-track milestones for the next year. Sets expectations for accountability at the next report.
Illustrative metrics · Year 1
Targets, not actuals.
- Cleared notional
- Planning target
- Default events
- 0
- Rule amendments
- 0
- Sev-1 incidents
- 0
- Clearing availability
- ≥ 99.995%
- Transparency-log gaps
- Zero tolerated
- Comment periods opened
- Each amendment
- Anchoring lapses
- Zero tolerated
Detailed figures disclosed in the report.
Target zero. Near-default events also disclosed.
Inventory of amendments with effective dates.
Targeting zero customer-impacting Sev-1 incidents in the steady-state year.
Target aligned with the operational-resilience disclosure.
No gaps or retroactive edits; the log is append-only.
One public comment window per material amendment.
Hourly anchoring to Ethereum and Bitcoin with documented fallback.
How the report is produced
From audit to anchor.
- Month 1 post FYComplete
Data compilation
All in-scope metrics compiled from the registry, the clearing engine, and the operational-resilience data warehouse. Each metric reconciled against its source ledger. - Month 2 post FYComplete
Independent audit
Independent audit by a tier-one firm of the cleared-volume, default and incident metrics. Findings incorporated before report finalisation. - Month 3 post FYComplete
Risk Committee review
Full report reviewed by the Risk Committee. Board sign-off on the final version. - Day of publicationComplete
Sign, anchor, publish
Report canonicalised (JCS), signed by the Chief Risk Officer, anchored in the transparency log and the public chains, then published on this site with download links for the signed artefact.
Ongoing obligations
Transparency is continuous.
A clearing house that won't publish its annual numbers is a clearing house that doesn't trust its own year. We publish ours — in full, signed, and cryptographically immutable.
Public documents
Every annual report — archived forever.
Transparency report archive
- FY 2026 — Annual report
First full-year transparency report. Target release 90 days after fiscal year end.
- Quarterly update notes
Published within 45 days after each quarter close.
- Metrics dictionary
Canonical definitions for every published metric.
- Restatement archive
Signed diffs against the original published version.
- Signed JSON artefacts
JCS-canonical JSON with anchor proofs against Ethereum and Bitcoin.
Verify what we publish
Proof, not assurance.
Download the signed JSON artefact and verify the hash against the public-chain anchors. This is transparency you can check in code, not trust by claim.