AffixIO logoAffixIO
Pricing

Compliance

What a reviewer needs to know before AffixIO sees your traffic.

A verification through AffixIO produces a decision, a signature and a digest. It does not produce a copy of your customer. This page sets out the data roles, the records that are kept and for how long, the evidence you can pull from the API, and the claims we will not make.

Sign In See it live
Position

The short version, in one paragraph

For verification traffic, AffixIO is a processor acting on your instructions, and you stay controller of the identity and eligibility records the check is drawn from. On the standard path nothing about a person needs to reach us: the SDK proves on your host, sends a proof and public inputs, and gets back a decision signed with ML-DSA-65. What we keep afterwards is a decision record and an audit leaf made of digests, identifiers and timestamps. The one exception is the document parsing helpers, where you send document text and we return the parsed fields without writing them down.

Data role
Processor for verification calls. Controller for Hub accounts and this website.
Kept after a check
Digests, decision, circuit id, timestamp, truncated key hash.
Proof retrieval window
7 days, then the proof is pruned.
Signature scheme
ML-DSA-65, NIST FIPS 204.

Nothing here is legal advice, and integrating AffixIO does not make your service compliant with any regime. It gives you a narrower data footprint to describe and better evidence to show.

Roles

Who is responsible for what

Most vendor arguments start because this table was never written down. Ours is written down.

Split of responsibility for a typical eligibility check.
ActivityYour organisationAffixIO
Lawful basis and privacy notice OwnerDecides the basis, writes the notice, handles objections. No role. We never see the subject to inform them.
Deciding the eligibility rule OwnerChooses the threshold, the circuit and the policy version. Compiles and hosts the circuit, records which version ran.
Holding the source records OwnerKeeps the document, the account record and the link to the person. Does not receive them on the prove and verify path.
Producing the proof OwnerRuns the SDK on your host or worker. Supplies the SDK, the circuit and the verifying key.
Verifying and signing the outcome Calls the endpoint and stores the returned attestation. OwnerVerifies the proof, signs the outcome, returns it.
Audit trail of decisions Keeps your own record and can reconcile against ours. OwnerAnchors digests in the Merkle tree, publishes the root.
Subject access and erasure requests OwnerLocates the person, answers within the statutory period. Assists on request. We cannot identify a person from a digest.
Retention schedule for identity data OwnerSets and enforces it in your environment. Applies the defaults in the ledger below to our own records.
Regulator notification after a breach OwnerNotifies the ICO or lead authority as controller. Reports incidents affecting your traffic to you without undue delay.
Key custody in your environment OwnerHolds API keys, device secrets and webhook secrets. Issues, rotates and revokes them on request in Hub.

The processor and controller split described here is the position AffixIO takes contractually. If your legal team needs it in a data processing agreement rather than on a web page, ask and we will send the paperwork.

Where data goes

Two paths, two very different data footprints

Confusing them is the most common mistake in a first integration, so it is worth being blunt about the difference.

Path A

Prove locally, verify remotely

The normal way to run AffixIO. Your host holds the personal data, generates a proof against a compiled circuit, and sends the proof rather than the facts.

What AffixIO receives
Circuit id, proof bytes, public inputs, an optional idempotency key, and the API key used.
What AffixIO returns
proof_id, valid, verified, decision, circuit_id, engine, proof_digest, proof_ref, return_value, policy_version and the ML-DSA-65 attestation.
What never arrives
Names, dates of birth, document numbers, addresses, images, biometric templates.
What is written down
A decision receipt and a Merkle leaf, both digest-based. See the ledger below.

Path B

Parsing helpers for document carriers

Two endpoints exist for teams that want AffixIO to read a document carrier rather than write their own parser. These do see personal data in the request.

Endpoints
POST /v1/mrz/parse for the machine-readable zone of a passport or ID card, and POST /v1/aamva/parse for the barcode string on a driving licence.
What happens to the input
It is parsed in memory. The fields and a SHA-256 digest of the input come back in the response. The parsed fields are not written to any AffixIO store.
What you should do
Call them server-side only, never from a browser, and prefer parsing on your own host when you can. Then send only the proof.
If your policy forbids it
Skip these endpoints entirely. Every circuit family works without them.

Digests are pseudonymous, not anonymous

A proof_digest contains no identity fields, but if your systems can map it back to an account then it is still personal data in your hands. The point of the split is that the linking data sits with you and the digest sits with us. Describe it that way in your records of processing rather than calling it anonymous.

Single use is enforced on our side

When a digest is verified in consume mode it is marked spent, so replaying the same proof returns a double spend rather than a second pass. That check needs the digest and nothing else, which is why it can live with a processor that holds no identity records.

Retention

The retention ledger

Every store AffixIO keeps that relates to your traffic, what sits in it, and how it ages out.

Current defaults. Where a limit is a count, the oldest record drops out first.
RecordContentsHow long it lasts
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 receipts.
Merkle audit leaf Digest, circuit id, proof id, event name, timestamp, leaf hash. Most recent 50,000 leaves.
Single-use digest register Spent digest and the time it was spent, used to detect replay. Most recent 50,000 digests.
Retrievable proof The proof itself plus its circuit and reference, so it can be fetched again for presentment. 7 days, and the 500 most recent proofs.
Idempotency record Request fingerprint and the response that was returned for it. 24 hours, in memory only.
API key usage log Truncated key hash, method, path, status code, timestamp. No bodies, no headers. Most recent 20,000 entries.
Hub account Email address, password verifier derived with scrypt, and your key and webhook configuration. Until you delete the account.
Hub session Session identifier bound to the account. 7 days, then pruned.
MCP OAuth grant Token digests, granted scope and the bound resource audience. Access token 1 hour, refresh token 30 days, authorisation code 5 minutes.
Website visitor record Hashed visitor token, page path, host, referrer host, viewport bucket, user agent, IP address and the coarse location derived from it. 90 days from the last visit.

What is deliberately absent

There is no request body log, no header dump and no store of witness values. A prove request is processed and the inputs go out of scope with it. The only field names that survive a prove call are the witness field names, not their values.

If you need shorter retention

The caps above are configurable per deployment, including running with the proof store disabled so nothing is retrievable after the response. Tell us the schedule your policy requires and we will confirm in writing what it changes.

Integration hygiene

Keep personal data out of the fields you control

AffixIO cannot stop a caller putting a customer's name in a free text field. These are the places it happens.

  1. Gate labels are free text, so keep them structural

    The entry_point field on a gate verify accepts up to 64 characters and is stored on the receipt. Use a door, till or queue identifier. Do not use a customer reference, an email address or a case number that resolves to a person in your CRM.

  2. Circuit ids reach the public counters

    The circuit breakdown at GET /api/governance-stats is public and lists circuit names with counts. Name circuits after the rule they enforce, such as ticket_season_holder, not after a client, a case or an individual.

  3. Idempotency keys should be random

    An idempotency key derived from an email address or a national insurance number turns a technical field into an identifier. Generate a UUID per attempt, or hash your own reference with a secret you keep.

  4. Webhook receipts still describe a real event

    Deliveries are signed with HMAC-SHA256 over {timestamp}.{body} and rejected outside a 300 second window, with three delivery attempts. The payload is pseudonymous, but it lands in your logging stack, so apply the same retention rules there as you would to any decision record about a customer.

  5. Keys belong on servers

    An API key in a browser bundle, a public repository or a model prompt is a disclosure, not a configuration mistake. Keep keys in server environments, workers or a secured MCP backend, and rotate through Hub if one leaks.

  6. Decide who can read the receipts

    GET /v1/verify/receipts returns up to 500 records per call for the key that asks. Treat that key as an audit credential and scope it accordingly, rather than sharing the same key across a front-of-house integration and a compliance dashboard.

Evidence

Evidence you can pull rather than request

A compliance claim that can only be confirmed by asking the vendor is a weak claim. These calls answer for themselves.

Public, no key

Audit counters and current root

curl -s https://api.affix-io.com/api/governance-stats

Returns leaf_count, merkle_root, last_leaf_ts, activity in the last 24 hours and 7 days, and a breakdown by circuit. Useful as a liveness and volume check before you integrate.

Public, no key

The root on its own

curl -s https://api.affix-io.com/v1/merkle/root

Returns root, leaf_count and updated_at. Snapshot it on a schedule and you can show later that a root you relied on was published at a given time.

Public, no key

Attestation public key

curl -s https://api.affix-io.com/.well-known/affix-mldsa65.json

Publishes the algorithm and the ML-DSA-65 public key, so a signed outcome can be checked offline, by you or by an auditor, without calling AffixIO at all.

Key required

Decision receipts

curl -s -H "X-API-Key: $AFFIX_KEY" \
  "https://api.affix-io.com/v1/verify/receipts?limit=100"

Mode, decision, reason code, timestamps, and whether a digest was already spent. Default 50 records, maximum 500 per call.

Key required

Audit leaves and inclusion

curl -s -H "X-API-Key: $AFFIX_KEY" \
  "https://api.affix-io.com/v1/merkle/leaves?limit=50"

Leaves carry the digest, circuit id, proof id, event and timestamp. Leaf and node hashes are domain separated with affix:leaf: and affix:node: over SHA-256, so an inclusion proof can be recomputed independently.

Key required

Evidence pack for an audit file

curl -s -H "X-API-Key: $AFFIX_KEY" \
  -O -J https://api.affix-io.com/ext/v1/compliance/export

A single JSON pack, schema affix.compliance.export.v1, holding the audit summary, recent leaves, key usage totals, webhook configuration with secrets masked, and a digest over the whole pack so the file can be shown to be intact.

Events an audit leaf can record

  • generated
  • proof_requested
  • verified
  • spent
  • revoked
  • scan_pass
  • scan_fail

The event name plus the digest is enough to reconstruct the sequence of a check. It is not enough to reconstruct the person it concerned.

Regulatory context

What is actually landing, and when

The dates that change verification work for UK and EU teams, as they stand in August 2026. Context for planning, not legal advice.

  1. In force since 5 February 2026

    UK data protection reform under the DUAA

    Most data protection provisions of the Data (Use and Access) Act 2025 commenced on 5 February 2026, adding the recognised legitimate interests basis, codifying reasonable and proportionate searches for subject access, and lifting PECR penalties to UK GDPR levels. The duty to run a data subject complaints procedure followed on 19 June 2026.

    Practical effect for verification work: your records of processing and DSAR playbook need to reflect what each vendor actually holds. A processor that holds digests is a short entry.

  2. Ongoing enforcement, UK

    Highly effective age assurance under the Online Safety Act

    Ofcom's July 2026 statutory report found deployment rising sharply, with the share of children meeting a robust age check moving from 25 per cent in July 2025 to 43 per cent by January 2026, alongside penalties against services that failed to put checks in place. Ofcom has ruled out age inference as highly effective for preventing child access, and committed to give Parliament a rapid assessment of over-16 age assurance by the end of October 2026.

    Practical effect: you must be able to evidence effectiveness in your own journey. A signed, replay-protected result helps you show what was checked and when. It does not settle the effectiveness question for you.

  3. Applies since 2 August 2026

    EU AI Act general application, with high-risk deferred

    The AI Act's general date of application was 2 August 2026, and the Article 50 transparency obligations apply from then. Regulation (EU) 2026/1744, in force since 27 July 2026, moved the core Annex III high-risk obligations to 2 December 2027 and Annex I product-embedded systems to 2 August 2028.

    Practical effect: if an agent or model decides access on your service, the permission check around it is worth designing now. A callable check that returns a signed allow or deny is easier to log than a prompt.

  4. By December 2026, then December 2027

    eIDAS 2 wallets and relying party duties

    Every EU member state must offer at least one certified EU Digital Identity Wallet by December 2026. Around December 2027, private relying parties in banking, telecoms, energy, transport and health, and very large online platforms, must accept the wallet where they perform strong customer authentication, and must register in a national relying party register declaring what data they request and why.

    Practical effect: the register entry forces you to justify each attribute you ask for. Designs that ask for a yes or no answer age better than designs that ask for a document.

  5. 2028, 2031, 2035

    Post-quantum migration timelines

    The NCSC expects discovery of your cryptographic estate and a written migration plan by 2028, the highest priority migrations by 2031, and full migration by 2035. ML-DSA is standardised as FIPS 204 and is on the recommended list.

    Practical effect: AffixIO signs verification outcomes with ML-DSA-65 today, so the attestation you keep is not a future migration item. Classical signatures in AffixIO materials are treated as quantum vulnerable. The NIST alignment page sets out publication by publication what is implemented, what is only partial and what is not claimed, including the absence of any cryptographic module validation. UK technical direction is covered on the NCSC alignment page. US CISA guidance is covered on the CISA alignment page.

Primary sources

Limits

What AffixIO does not claim

Reviewers spend most of their time separating capability from marketing. Here is the separation, done for you.

  • No ISO 27001 certificate and no SOC 2 report. We hold neither at present and publish nothing that implies otherwise. What we offer instead is the technical detail on this page and evidence you can pull yourself.
  • No cryptographic module validation. Signing uses ML-DSA-65 as standardised in FIPS 204, which is an algorithm claim rather than a certificate. There is no FIPS 140-3 validation and no CMVP entry. The NIST alignment page covers this in full.
  • Not an accredited age assurance provider. We do not certify that your deployment meets the highly effective standard, and we do not act as your assessor.
  • Not your DPO, and not legal advice. The regulatory context above is planning material. Your lawful basis, notices and retention schedule are yours to decide.
  • No bulk personal data feeds. We will not take a copy of your customer database to make onboarding easier. If a proposed design needs that, it is the wrong design for this product.
  • No claim that digests are anonymous. They are pseudonymous. Where you can re-identify from your own side, treat them accordingly.
  • No invented customer list. You will not find logos or testimonials on this site that we cannot stand behind, which is why there are none.
Sub-processors

Who else is in the path

A short list, because the verification path is deliberately thin.

Outbound calls made by AffixIO services.
SurfaceOutbound callsNotes
Verification and prove None to third parties. No identity vendor, no email or SMS provider, no analytics platform, no model API.
Webhooks Your endpoint only. Signed with HMAC-SHA256, 300 second replay window, three attempts. You choose the destination.
MCP server Internal to the API. OAuth 2.1 with PKCE and audience binding to the MCP resource. Your model client is the other party.
This website ipwho.is, geojs.io. IP lookups used to derive coarse location for the visitor record described below. Not used in verification.

The visitor record on this site

Browsing affix-io.com stores a visitor token in local storage for 90 days. The API keeps a hashed form of that token with the page path, host, referrer host, viewport bucket, user agent, IP address and the coarse location derived from it. AffixIO is controller for that record. Clearing site data in your browser removes the token, and the server record expires 90 days after your last visit.

Infrastructure and locations

Hosting providers and processing locations are confirmed in writing in the questionnaire pack rather than stated loosely here, because the answer needs to be specific to the deployment you are buying. Ask and you will get the current list with the contractual position that goes with it.

DPIA support

Filling in the assessment

The questions a DPIA or vendor questionnaire will ask about AffixIO, and where each answer comes from.

What categories of personal data does the processor receive?
None on the prove and verify path. Document carrier text if, and only if, you choose to call the parsing helpers. See where data goes.
What is the lawful basis and who decides it?
You decide, as controller. AffixIO processes on your instructions under the split in the responsibility matrix.
Is the processing necessary and proportionate?
The check returns a binary outcome against a rule you define. Argue proportionality on the basis that no attribute value is disclosed to reach that outcome.
What is retained, where and for how long?
Record by record in the retention ledger, including the 7 day proof window and the count-based caps on receipts, leaves and spent digests.
How are individuals' rights supported?
You hold the identity link, so access and erasure are executable in your environment. We assist with reconciliation using digests you supply.
What are the security measures?
ML-DSA-65 attestation, SHA-256 digests with domain separated Merkle hashing, single use enforcement, HMAC-signed webhooks, OAuth 2.1 with PKCE for MCP, per-key rate limits and revocable keys. Disclosure route on the security page.
Are there international transfers?
Answered specifically for your deployment in the questionnaire pack, with the contractual mechanism, rather than asserted generically here.
How would we evidence a decision months later?
Attestation signature, Merkle inclusion against a published root, and the decision receipt. See evidence.
What happens if the vendor disappears?
Attestations verify offline against the published public key, and inclusion proofs verify against roots you have already snapshotted. Keep both alongside your own records.

Send the questionnaire itself to Contact. Tell us whether the integration is server-side, agent-driven through MCP, or using the parsing helpers, because those three shapes have different answers.

Questions

Compliance questions, answered directly

Data roles, retention, evidence and the boundaries of what AffixIO will say.

Is AffixIO a controller or a processor?

Both, depending on the traffic. For verification calls to api.affix-io.com, AffixIO is a processor acting on your instructions and you remain controller of the identity and eligibility records behind the check. For Hub accounts and for this website, AffixIO is the controller of the account and visit records it keeps.

What personal data does AffixIO store after a verification?

On the standard prove and verify path, a decision record and an audit leaf made up of digests, a circuit identifier, a proof identifier, an event name, a timestamp and a truncated hash of the API key used. Names, dates of birth, document numbers and images are not part of those records, because the check runs against a proof rather than the underlying document.

How long does AffixIO keep verification records?

A generated proof stays retrievable for 7 days. Decision receipts, audit leaves and the single-use digest register are capped by count rather than age, at 20,000 receipts and 50,000 leaves and digests in the current defaults, with the oldest records dropping out first. Hub sessions expire after 7 days, MCP access tokens after 1 hour and refresh tokens after 30 days. The website visitor record expires 90 days after the last visit.

Which AffixIO endpoints can see document data?

Only the parsing helpers. POST /v1/mrz/parse and POST /v1/aamva/parse take the machine-readable zone of a travel document or the barcode string from a driving licence, parse it in memory, return the fields with a SHA-256 digest of the input, and do not write the parsed fields to any store. Every other verification endpoint works on proofs, public inputs and digests.

Does a proof digest count as personal data?

Treat it as pseudonymous rather than anonymous. A digest carries no identity fields, but if your own systems can link it back to a person then it remains personal data in your hands under UK and EU data protection law. That is the point of the split: the linking data stays with you, the digest sits with us.

What evidence can I produce if a regulator asks what happened in a check?

Three artefacts. The ML-DSA-65 attestation signed over the outcome, verifiable offline against the published public key. The Merkle inclusion proof showing the digest was anchored, checkable against the public root at GET /v1/merkle/root. The decision receipt from GET /v1/verify/receipts, giving mode, decision, reason code, timestamp and whether the digest had already been spent.

Does using AffixIO make my age checks compliant with the Online Safety Act?

No. Ofcom assesses whether a service's age assurance is highly effective in context, covering the method, the user journey and the evidence behind it, not a single component. AffixIO can carry the result of an age check and sign it. Choosing the method, evidencing effectiveness and documenting that decision stay with your organisation.

Is AffixIO ISO 27001 certified or does it have a SOC 2 report?

No. AffixIO holds neither at present and publishes no claim that implies otherwise. What is available is the technical detail on this page, a completed vendor questionnaire on request, and evidence you can pull directly from the API rather than take on trust.

Who are AffixIO's sub-processors for verification traffic?

The verification path calls no third-party identity vendor, no email or SMS provider, no analytics platform and no model API. Outbound calls from a verification are limited to webhooks addressed to endpoints you configure. Two IP geolocation lookups, ipwho.is and geojs.io, serve the website visitor record only. Ask us for the current infrastructure provider list and processing locations.

Can AffixIO complete our vendor security questionnaire and DPIA annex?

Yes. Email https://www.affix-io.com/contact/ with the questionnaire and the deployment you have in mind. Say whether you plan to use the parsing helpers, whether webhooks will be enabled, and whether the integration is server-side or through the MCP server, because those choices change which data reaches AffixIO.

Bring us the awkward questions

The useful conversations start with a specific deployment, a specific regulator and a specific retention rule. Send those and we will answer in writing, including where the answer is no.

If you would rather see it working before you read paperwork, Edge Audit runs an eligibility proof where the personal fields never leave the host.

Email the compliance team Open Edge Audit

Page reviewed 14 August 2026. Retention figures and endpoint behaviour describe current defaults and can change per deployment. Where this page and a signed contract differ, the contract governs.