Getting Started

Everything you need to integrate CCPAtlas into your analytics, risk, or research systems.

Introduction

CCPAtlas is a REST API providing structured, queryable access to the CPMI-IOSCO Public Quantitative Disclosures (PQD) published every quarter by central counterparties (CCPs). It replaces the manual process of downloading Excel files from each CCP's website with a single, consistent, filterable interface across every major clearing house globally.

The API is designed for consumption by risk analytics platforms, credit systems, research teams, regulatory reporting engines, and internal dashboards. All data is normalised to a common schema, all monetary values can be converted at historical exchange rates, and every response is stable and versioned.

Who uses CCPAtlas?

CCPAtlas serves a broad range of institutions that need reliable, comparable CCP disclosure data:

  • Banks and clearing members monitoring their exposures, default-fund contributions, and margin requirements across the CCPs they clear through.
  • Pension funds and asset managers evaluating clearing relationships and counterparty risk.
  • Regulators, central banks, and supervisory authorities tracking systemic risk and the resilience of financial market infrastructures.
  • Standard-setting bodies and international organisations analysing disclosure practices and CCP resilience across jurisdictions.
  • Academic and educational institutions — business schools, finance faculties, and researchers studying central clearing, market structure, and post-crisis reform.
  • Risk consultancies, data vendors, and fintech platforms building analytics on top of standardised CCP data.
  • Research teams analysing CCP behaviour across market events such as the March 2020 volatility.

What are the PQDs, and why do they matter?

The Public Quantitative Disclosures (PQDs) are a standardised set of quantitative data points that central counterparties publish about their financial resources, risk exposures, margin, default funds, liquidity, and operational performance. They are the closest thing the cleared-derivatives market has to a common, comparable "financial statement" for CCPs.

A brief history

In the aftermath of the 2007–09 financial crisis, global regulators moved large parts of the derivatives market into central clearing to reduce counterparty risk. That concentration made CCPs systemically important — and made transparency about their resilience essential. The foundations were laid by the CPSS-IOSCO Principles for Financial Market Infrastructures (PFMI), published in April 2012, which set out (in Principle 23) that CCPs should make relevant information publicly available.

To turn that principle into concrete, comparable numbers, the Committee on Payments and Market Infrastructures (CPMI) and the International Organization of Securities Commissions (IOSCO) published the Public quantitative disclosure standards for central counterparties on 26 February 2015. CCPs were encouraged to begin publishing the minimum set of disclosures by 1 January 2016 at the latest, updated quarterly. In November 2017, the industry body CCP Global released a harmonised PQD template that CCPs around the world adopted, further improving standardisation and comparability.

The framework continues to evolve. Following the March 2020 market turmoil and the subsequent review of margining practices, CPMI-IOSCO consulted during 2026 on additional disclosures relating to initial-margin transparency and responsiveness — meaning the PQD dataset is set to deepen further.

Why they matter

  • They make CCPs comparable. Before the PQDs, assessing one clearing house against another meant wrestling with inconsistent, ad-hoc disclosures. The PQDs impose a common template across ~200 data points.
  • They are central to counterparty risk management. Clearing members and their clients use PQD data to size and monitor their exposure to each CCP — default-fund contributions, margin held, stress-test coverage, and concentration.
  • They underpin systemic-risk oversight. Regulators, central banks, and standard-setters rely on the PQDs to monitor the resilience of the market infrastructures now sitting at the centre of global derivatives markets.
  • They are quarterly and cumulative. Because every major CCP publishes on the same quarterly cadence, the PQDs form a growing time series that reveals trends, stress responses, and structural shifts over time.
Where CCPAtlas fits.

The PQDs are public — but they are scattered across dozens of CCP websites, published as individual spreadsheets in differing layouts, with inconsistent naming and no common query interface. Assembling a single, clean, comparable time series across every major CCP is a significant and recurring data-engineering task. CCPAtlas does exactly that: it consolidates, normalises, and serves the entire PQD universe through one consistent, versioned API — turning a fragmented public dataset into an analysis-ready resource.

Quick start

Once you have an API key, you can query CCPAtlas in three steps:

  1. Get your API key by emailing ccpatlas@altairalang.com.
  2. Send it in the X-API-Key header on every request.
  3. Filter data with query parameters.
curl -H "X-API-Key: YOUR_API_KEY" \
  "https://api.ccpatlas.com/v1/data?ccp=ICC&disclosure=6.2&limit=5"

Prefer to explore without writing code? Try the Data Explorer — a web interface with cascading dropdowns and CSV export.

What's included

CCPAtlas provides complete coverage of the CPMI-IOSCO Public Quantitative Disclosure framework, spanning:

  • 72 central counterparties across Americas, EMEA, and APAC regions
  • 205 individual disclosure references organised into 47 disclosure sections
  • 10 years of quarterly history for Enterprise-tier clients (3 years for Professional)
  • All reported currencies preserved as-is, plus historical conversion to any of the supported target currencies

Every quarter, new disclosures published by CCPs are ingested, validated, and made available typically within two weeks of publication.

CCPs covered

The 72 CCPs currently in CCPAtlas span every major clearing house globally. This includes derivatives clearing (LCH SwapClear, ICE Clear Credit, CME Clearing), equity and futures clearing (LCH Ltd, Eurex, Japan Securities Clearing), commodity clearing (ICE Clear Europe, EEX), and regional operators across all three regions.

Programmatic access via GET /v1/ccps — see the API Reference for the full response schema.

Disclosure references

Each of the 205 disclosure references maps to a specific quantitative measurement defined by the CPMI-IOSCO framework — for example, initial margin held by the CCP, default fund contributions, or liquid resources by tenor. References are organised into sections (4.x margin, 5.x collateral, 6.x default resources, 7.x credit risk, 15.x liquidity risk, 20.x collateral, etc).

Each reference includes:

  • Disclosure — the parent section (e.g. 6.2)
  • Reference — the specific line item (e.g. 6.2.15)
  • Disclosure Title — plain-English name (e.g. "Total initial margin required")
  • Disclosure Description — clarifying detail from the CPMI-IOSCO framework
  • Data Type — Numeric, Currency, Percentage, Date, Time, or Text

Programmatic access via GET /v1/disclosures supports plain-English search by title or description.

Quarterly refresh

Under the CPMI-IOSCO framework, CCPs publish PQD data quarterly with report dates on 31 March, 30 June, 30 September, and 31 December. Publications typically appear on each CCP's website 6-8 weeks after the reporting quarter.

How CCPAtlas ingests new data

Our data operations team runs the following process every quarter:

  1. Collection: Once all in-scope CCPs have published their quarterly disclosures (typically mid-to-late in the second month after quarter-end), source files are gathered.
  2. Normalisation: Values are mapped to the common CCPAtlas schema, currency codes standardised to ISO 4217, dates aligned to quarter-end.
  3. Validation: Automated checks: all expected references present per CCP, values within statistical bands of historical norms, disclosure references matching the master dictionary, currencies matching ISO codes.
  4. Loading: A single-transaction load into the database. Data goes into "draft" state — clients cannot see it yet.
  5. Publish: After manual review of the validation report, the release is published atomically and becomes visible to clients.
  6. Notification: Enterprise clients receive an email listing the newly available reporting date and any material changes.

Typical end-to-end lead time from CCP publication to CCPAtlas availability is 10-14 days. If a CCP subsequently reissues a corrected quarter, we reload that quarter and notify affected clients.

Checking data recency

Every /v1/data response includes the latest report_date per CCP in meta. You can also call GET /v1/periods for a summary of what quarters are available per CCP.

Base URL & versioning

All endpoints live under a versioned path:

https://api.ccpatlas.com/v1/

The v1 version prefix is the API contract you integrate against. Within v1, we never introduce breaking changes: new endpoints, new response fields, and new optional parameters may be added, but existing behaviour is stable. When we make breaking changes, they land under a new prefix (v2) and v1 continues to serve as-is for at least 12 months.

This is different from the service version (currently 1.0.0), which identifies the deployed build. You can see the current service version by calling GET /v1/health.

Authentication

Every request to a /v1/ data endpoint must include your API key in the X-API-Key HTTP header.

X-API-Key: YOUR_API_KEY

Key management

  • Keys are hashed with SHA-256 in our database. We never store your key in plaintext.
  • If you lose your key, we cannot recover it. We can revoke and reissue.
  • Keys are issued to an organisation, not an individual, and may be used by your team. You can have multiple keys per organisation (e.g. one per environment, team, or user) — each has its own label and can be revoked independently, which is the recommended way to track usage per team or per person.
  • Professional and Enterprise keys typically expire after 365 days. Sandbox evaluation keys expire after 7 days. Contact us before expiry to rotate or convert.

Sandbox (evaluation) keys

Sandbox keys are scoped for evaluation: they see a limited set of CCPs and a fixed historical window, are restricted to JSON (no data export), and are subject to lower usage caps. Responses carry meta.evaluation_only: true. They are intended for assessing the API's shape and data quality, not for production or commercial use.

Treat keys like passwords.

Never commit them to git, never share them publicly, never expose them in browser-based client code. Use environment variables in server-side code and a secrets manager in production. If a key is exposed, contact us and we will revoke and reissue it immediately.

Access tiers

Your API key is provisioned against a tier that determines what data you can access and at what rate. CCPAtlas offers a free evaluation Sandbox tier alongside the paid Professional and Enterprise tiers.

FeatureSandbox (evaluation)ProfessionalEnterprise
Purpose7-day trial / evaluationResearch teams & smaller institutionsBanks, regulators & central banks
Historical lookbackA fixed 2-quarter window (~1 year ago)3 years10 years
CCP coverageUp to 5 selected CCPsAll 72 CCPsAll 72 CCPs
Disclosure granularityHigh-level onlyHigh-level onlyHigh-level + detailed
Output formatsJSON only (no export)JSON, CSVJSON, CSV
Rate limit10 req/min60 req/min300 req/min
Usage caps100/day, 300 over the trial100,000 / monthUnmetered
Commercial useNo — evaluation onlyYesYes
SupportBest effortEmail supportPriority + SLA

The API enforces tier restrictions server-side. If you request data outside your tier's window or scope, the response is clamped (or narrowed to your permitted CCPs) and a warning is returned in meta.warnings — you can see exactly what was restricted. Sandbox responses are additionally marked with meta.evaluation_only: true.

Evaluating CCPAtlas?

The Sandbox tier lets prospective clients try the API against a limited, representative slice of the data — a handful of CCPs across two historical quarters — before committing to a paid plan. It's approved on request for institutional evaluators. Contact ccpatlas@altairalang.com to arrange one.

High-level vs detailed disclosures

The Professional and Sandbox tiers return high-level disclosures: the headline figures and aggregate totals for each CCP. The Enterprise tier additionally returns detailed disclosures: the granular breakdowns beneath those totals — per-clearing-service splits, per-currency and per-counterparty decompositions, model internals, back-testing distributions, and stress detail.

Aggregate totals remain visible at every tier. For example, a Professional client sees the total initial margin held by a CCP (the aggregate row); an Enterprise client additionally sees that total broken down by each individual clearing service. The headline is never hidden — only the decomposition is Enterprise-only.

The table below summarises, by PQD disclosure area, how many references are classified high-level (all tiers) versus detailed (Enterprise only). Every reference's exact classification is returned in the API and shown in the Data Explorer's column tools.

Disclosure areaHigh-level (all tiers)Detailed (Enterprise)
4 — Default resources & credit risk1620
5 — Collateral & haircuts06
6 — Margin339
7 — Liquidity risk172
12 — Settlement60
13 — Default management05
14 — Client positions40
15 — General business risk110
16 — Custody & investment224
17 — Operational risk23
18 — Participant & concentration99
19 — Tiered participation60
20 — FMI links59
23 — Volumes & values17

In short: Professional gives you the complete set of headline figures across all CCPs and disclosure areas; Enterprise adds the full granular decomposition for deep risk, margin, and financial analysis. To discuss which tier fits your use case, contact ccpatlas@altairalang.com.

The /v1/data endpoint is where most work happens. Every filter is an optional query parameter. Multiple filters combine with AND semantics.

ParameterDescriptionExample
ccpCCP code(s), comma-separatedICC - Ice Clear Credit
ccp_groupParent group nameICE
regionGeographic regionAmericas
countryCountry nameUnited States of America
cityCityChicago
report_date_fromISO date, inclusive2024-01-01
report_date_toISO date, inclusive2024-12-31
disclosureTop-level section6.2
referenceSpecific reference6.2.15
report_levelReporting scopeClearing_Service
report_level_identifierSub reporting scopeICC_CDS
currencySource currency of the valueUSD
searchFree-text search across disclosure titles/descriptionsdefault fund
limitRows per page (max 10,000)500
offsetRows to skip for pagination0
formatjson (default) or csvcsv

See the API Reference for the full parameter list and response schema.

Currency conversion

Add output_currency=XXX to any /v1/data call to convert monetary values in the response. This is one of CCPAtlas's core analytical features.

GET /v1/data?ccp=ICC&disclosure=6.2&output_currency=USD

Historical rates, not today's rates

CCPAtlas uses the exchange rate as it stood on the row's report_date, not today's rate. This matters more than it might look. If ICC reported EUR 10bn of initial margin on 31 December 2020, the correct USD value is 10bn × the EUR/USD rate on 31 December 2020, not today's rate. Using today's rate to convert historical values silently produces wrong time-series and misleads regulatory analysis.

Rate source and methodology

  • Source: European Central Bank reference rates via the Frankfurter API.
  • Base currency: EUR. All conversions go source → EUR → target as a cross-rate.
  • Frequency: ECB publishes rates once per business day. CCPAtlas caches every published rate for every supported currency.
  • Weekends and holidays: ECB does not publish rates on weekends or ECB holidays. Quarter-end dates that fall on non-business days (e.g. 31 December 2022 was a Saturday) use the most recent published rate before that date — typically the preceding Friday.

What the response includes

Every converted row includes three additional fields alongside the original value:

  • converted_value — the value in your target currency
  • fx_rate — the exact rate used for that row
  • fx_rate_date — the date that rate was sourced from (usually equals report_date; may differ if that fell on a weekend)

The original value and currency fields are preserved unchanged.

Rows that can't be converted

Some rows have no source currency to convert (a percentage, a text field, a date). These are returned unchanged with converted_value: null. The meta.warnings array will note this if it happens.

Supported currencies

Call GET /v1/currencies to list every currency you can pass to output_currency. All ECB-published currencies are supported (~30 including USD, EUR, GBP, JPY, CHF, CAD, AUD, NZD, NOK, SEK, DKK, PLN, CZK, HUF, and more).

Response format

JSON responses have a consistent envelope:

{
  "meta": {
    "request_id": "abc-...",
    "timestamp": "2026-07-17T12:00:00Z",
    "tier": "enterprise",
    "filters_applied": { ... },
    "pagination": { "limit": 500, "offset": 0, "total": 1234, "returned": 500 },
    "fx": { ... },
    "warnings": []
  },
  "data": [
    {
      "ccp_code": "ICC",
      "ccp_name": "ICE Clear Credit",
      "report_date": "2026-03-31",
      "reference": "6.2.15",
      "value": 15234000000.00,
      "currency": "USD",
      ...
    },
    ...
  ]
}

The meta object gives you everything about how your query was processed — including any tier clamping or FX warnings. The data array contains the rows themselves.

Pagination

Use limit (max 10,000) and offset to page through large result sets. The response's meta.pagination.next_offset tells you when to stop:

let offset = 0;
while (true) {
  const r = await fetch(`${API}/v1/data?limit=1000&offset=${offset}`, ...);
  const d = await r.json();
  process(d.data);
  if (d.meta.pagination.next_offset === null) break;
  offset = d.meta.pagination.next_offset;
}

For bulk extractions, use format=csv with a large limit instead — streaming CSV is much more efficient than paged JSON.

Error handling

Errors follow RFC 7807 (Problem Details for HTTP APIs). Every error response has this shape:

{
  "type": "https://ccpatlas.com/errors/invalid-currency",
  "title": "Invalid output_currency",
  "status": 400,
  "detail": "'ZZZ' is not a supported conversion currency. See /v1/currencies.",
  "instance": "/v1/data"
}

Common status codes:

  • 200 — Success
  • 400 — Bad request (invalid parameter)
  • 401 — Missing or invalid API key
  • 403 — Authenticated but tier restriction blocks the request
  • 404 — Endpoint or resource not found
  • 422 — Request validation failed (with a per-field breakdown)
  • 429 — Rate limit exceeded, retry after the delay in the header
  • 500 — Something went wrong on our end

Every response carries an X-Request-ID header. Include it when contacting support — we use it to trace the exact request in our logs.

Rate limits

Rate limits and usage caps are enforced per organisation, across all of that organisation's keys:

  • Sandbox: 10 requests per minute, 100 per day, and a total of 300 requests over the 7-day evaluation.
  • Professional: 60 requests per minute, 100,000 per calendar month.
  • Enterprise: 300 requests per minute, unmetered monthly.

When you exceed a per-minute, daily, or monthly limit, the response is 429 Too Many Requests with a Retry-After header telling you how long to wait. Well-behaved clients back off exponentially rather than retrying immediately. On the Sandbox tier, once the total evaluation budget is exhausted the response is 403 — at that point, contact us to move to a paid plan.

Every response also carries rate-limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) so you can track your usage programmatically.

Security

CCPAtlas is built for institutions with strict information security requirements. Every layer of the stack has been designed with defensible controls, and we can support formal due diligence questionnaires from procurement and information security teams.

Transport

  • TLS 1.2 minimum. HTTPS enforced on all endpoints. Plain HTTP is redirected. Weak ciphers disabled.
  • Perfect forward secrecy via ephemeral key exchange.
  • Certificates managed by Azure with automatic rotation before expiry.
  • HSTS enabled with a 1-year max-age.

Authentication and authorisation

  • API keys are SHA-256 hashed at rest. We cannot recover a lost key — only revoke and reissue.
  • Keys are tier-scoped and enforced server-side. There is no client-side trust boundary.
  • Every key has an expiry date (default 365 days) enforced at authentication time.
  • Keys can be revoked instantly. Revocation propagates on the next request.

Data protection

  • Encryption at rest. Azure Storage and PostgreSQL use AES-256 encryption managed by Azure.
  • Private database. The database is not internet-exposed. Only the API service can reach it, via a private connection inside our Azure environment.
  • Secrets in Azure Key Vault. Database credentials, API keys, and all other secrets are stored in Key Vault with role-based access control and audit logging. They are never in source code or environment variables at rest.

Audit and logging

  • Every request is logged with request ID, API key ID (not the key itself), endpoint, response code, and elapsed time.
  • Every administrative action (key issue, key revocation, data ingestion, publication) is written to an immutable audit log.
  • Ingestion is auditable end-to-end. Every quarterly load is tied back to the source files, which are retained in immutable blob storage for 7 years.

Infrastructure

  • Hosted on Microsoft Azure (UK South region — data residency attestable for UK and EU regulatory requirements).
  • Managed identity for all inter-service authentication — no shared secrets between our components.
  • Regular security patching via container image rebuilds; base images updated on each release cycle.

Operational

  • Access to production restricted to named personnel, authenticated with Microsoft Entra ID single sign-on and MFA.
  • Least-privilege by default. Different roles have different scopes; no engineer has permanent production database write access.
  • Change management. All production deployments go through pull request, code review, and an explicit approval gate.
Security questionnaires welcome.

We can complete standard due diligence questionnaires (SIG, CAIQ, custom) for prospective enterprise clients. Contact ccpatlas@altairalang.com to request.

Endpoint overview

The full endpoint reference lives at API Reference. Here's the summary:

GET
/v1/health
Service liveness (public, no auth)
GET
/v1/currencies
Supported currencies for FX conversion
GET
/v1/ccps
CCP reference data with metadata
GET
/v1/disclosures
Disclosure reference list with titles
GET
/v1/periods
Available reporting periods
GET
/v1/facets
Distinct filter values (used by the Explorer)
GET
/v1/data
The main data query endpoint

Code examples

Python

import os, requests

resp = requests.get(
    "https://api.ccpatlas.com/v1/data",
    headers={"X-API-Key": os.environ["CCPATLAS_KEY"]},
    params={
        "ccp_group": "ICE",
        "disclosure": "6.2",
        "report_date_from": "2024-01-01",
        "output_currency": "USD",
        "limit": 500,
    },
    timeout=30,
)
resp.raise_for_status()
data = resp.json()
print(f"{data['meta']['pagination']['total']} rows available")
for row in data["data"]:
    print(row["ccp_code"], row["report_date"], row["reference"], row["converted_value"])

JavaScript / TypeScript

const params = new URLSearchParams({
  ccp_group: "ICE",
  disclosure: "6.2",
  output_currency: "USD",
  limit: "500",
});
const r = await fetch(`https://api.ccpatlas.com/v1/data?${params}`, {
  headers: { "X-API-Key": process.env.CCPATLAS_KEY },
});
if (!r.ok) throw new Error(`${r.status} ${await r.text()}`);
const { meta, data } = await r.json();
console.log(`${meta.pagination.total} rows available`);

Bulk export to CSV

curl -H "X-API-Key: $CCPATLAS_KEY" \
  "https://api.ccpatlas.com/v1/data?ccp_group=ICE&format=csv&limit=10000" \
  -o ice_disclosures.csv

Discover disclosures with plain-English search

GET /v1/disclosures?search=default+fund

Returns every reference whose title or description mentions default fund, with data type and granularity metadata.

Support

Questions, feature requests, or issues — email ccpatlas@altairalang.com and include the X-Request-ID from your response if reporting a problem.

Enterprise clients additionally have access to priority support with scheduled Microsoft Teams calls and named support contacts. Response-time targets and escalation details are set out in our Support & Service Level Statement and provided at onboarding.