# AffixIO compliance reference

Canonical page: https://www.affix-io.com/compliance/
Security page: https://www.affix-io.com/security/
Product page: https://www.affix-io.com/product/
API base: https://api.affix-io.com
Site brief: https://www.affix-io.com/llms.txt
Extended brief: https://www.affix-io.com/llms-full.txt
Contact: hello@affix-io.com

A verification through AffixIO produces a decision, an ML-DSA-65 signature and a digest. On the standard path it does not produce a copy of the person. This file summarises data roles, retention, audit evidence and the claims AffixIO refuses to make.

## Data roles

- Verification traffic to api.affix-io.com: AffixIO is processor, acting on customer instructions. The customer is controller of the identity and eligibility records the check is drawn from.
- Hub accounts at hub.affix-io.com and the www.affix-io.com website: AffixIO is controller of the account and visit records it keeps.
- Customer keeps: lawful basis, privacy notice, eligibility rule, source records, subject access and erasure, regulator notification as controller, key custody in its own environment.
- AffixIO keeps: circuit hosting and versioning, proof verification, ML-DSA-65 attestation, Merkle anchoring, key issue, rotation and revocation in Hub, incident reporting to the customer.

## Two data paths

Path A, prove locally and verify remotely (normal use):
- AffixIO receives: circuit id, proof bytes, public inputs, optional idempotency key, API key.
- AffixIO returns: proof_id, valid, verified, decision, circuit_id, engine, proof_digest, proof_ref, return_value, policy_version, ML-DSA-65 attestation.
- AffixIO does not receive names, dates of birth, document numbers, addresses, images or biometric templates.

Path B, document parsing helpers (optional):
- `POST /v1/mrz/parse` and `POST /v1/aamva/parse` accept document carrier text that contains personal data.
- Input is parsed in memory. Fields and a SHA-256 digest of the input are returned. Parsed fields are not written to an AffixIO store.
- Guidance: call server-side only, prefer parsing on the customer host, and skip these endpoints if policy forbids sending document text to a processor.

## Retention defaults

- Decision receipt (receipt id, timestamp, mode, allow, valid, reason code, circuit id, proof and gate identifiers, spent and double spend flags, truncated key hash): most recent 20,000.
- Merkle audit leaf (digest, circuit id, proof id, event, timestamp, leaf hash): most recent 50,000.
- Single-use digest register: most recent 50,000.
- Retrievable proof: 7 days and the 500 most recent proofs.
- Idempotency record: 24 hours, memory only.
- API key usage log (truncated key hash, method, path, status, timestamp): most recent 20,000. No request bodies or headers are logged.
- Hub account: until deleted. Hub session: 7 days.
- MCP OAuth: access token 1 hour, refresh token 30 days, authorisation code 5 minutes.
- Website visitor record (hashed token, path, host, referrer host, viewport bucket, user agent, IP, coarse location): 90 days from last visit.

Count-based limits drop the oldest record first. Caps are configurable per deployment, including running with the proof store disabled.

## Audit evidence

Public, no key required:
- `GET https://api.affix-io.com/api/governance-stats` - leaf_count, merkle_root, last_leaf_ts, 24h and 7d activity, circuit breakdown.
- `GET https://api.affix-io.com/v1/merkle/root` - root, leaf_count, updated_at.
- `GET https://api.affix-io.com/.well-known/affix-mldsa65.json` - algorithm and ML-DSA-65 public key for offline signature checks.

Key required:
- `GET /v1/verify/receipts` - decision receipts, default 50 per call, maximum 500.
- `GET /v1/merkle/leaves` - audit leaves for inclusion checks.
- `GET /ext/v1/compliance/export` - JSON evidence pack, schema `affix.compliance.export.v1`, with audit summary, recent leaves, key usage totals, webhook configuration with secrets masked, and a digest over the pack.

Merkle hashing is SHA-256 with domain separation prefixes `affix:leaf:` and `affix:node:`. Audit events: generated, proof_requested, verified, spent, revoked, scan_pass, scan_fail.

Webhook deliveries are signed with HMAC-SHA256 over `{timestamp}.{body}`, rejected outside a 300 second window, with three delivery attempts.

## Integration hygiene

- `entry_point` on gate verify is free text up to 64 characters and is stored on the receipt. Use a door, till or queue identifier, not a customer reference.
- Circuit ids appear in the public circuit breakdown. Name circuits after the rule, not after a client or an individual.
- Generate random idempotency keys. Do not derive them from an email address or a national identifier.
- Treat digests as pseudonymous, not anonymous. If the customer can re-identify from its own systems, the digest is personal data in the customer's hands.
- Keep API keys server-side. Never in browser bundles, public repositories or model prompts.

## Regulatory context, August 2026

- UK: most data protection provisions of the Data (Use and Access) Act 2025 commenced 5 February 2026; the data subject complaints procedure duty commenced 19 June 2026.
- UK age assurance: Ofcom's July 2026 statutory report recorded robust age checks rising from 25 per cent in July 2025 to 43 per cent by January 2026, ruled out age inference as highly effective for preventing child access, and committed to a rapid assessment of over-16 age assurance for Parliament by end of October 2026.
- EU AI Act: general date of application 2 August 2026 with Article 50 transparency obligations applying. Regulation (EU) 2026/1744 moved Annex III high-risk obligations to 2 December 2027 and Annex I to 2 August 2028.
- eIDAS 2: each member state must offer a certified EU Digital Identity Wallet by December 2026; private relying parties in banking, telecoms, energy, transport and health, and very large online platforms, must accept wallets around December 2027 and register as relying parties first.
- Post-quantum: NCSC expects discovery and a migration plan by 2028, highest priority migrations by 2031, full migration by 2035. ML-DSA is FIPS 204.

Sources: ico.org.uk, gov.uk, ofcom.org.uk, eur-lex.europa.eu, ncsc.gov.uk, csrc.nist.gov.

## Sub-processors and outbound calls

- Verification and prove: no third-party identity vendor, no email or SMS provider, no analytics platform, no model API.
- Webhooks: customer-configured endpoints only.
- MCP server: internal to the API, OAuth 2.1 with PKCE and audience binding.
- Website only: ipwho.is and geojs.io IP lookups for the visitor record.
- Infrastructure providers and processing locations are confirmed in writing per deployment, not asserted on the page.

## Limits of these claims

- AffixIO holds no ISO 27001 certification and no SOC 2 report, and publishes no claim implying either.
- AffixIO is not an accredited age assurance provider and does not certify that a deployment meets Ofcom's highly effective age assurance standard.
- Nothing on the compliance page is legal advice, and AffixIO does not act as a customer's data protection officer.
- AffixIO does not accept bulk personal data feeds.
- Digests are pseudonymous, not anonymous.
- Retention figures are current defaults and may differ under contract. Where the page and a signed contract differ, the contract governs.

Last updated: 2026-08-14