PCI posture

What this is: where Loop sits on the PCI-DSS spectrum today, where it can grow to, and the design rules that make the growth a capability you grow into rather than a rewrite.

Who it’s for: anyone reasoning about compliance scope, vendor selection, or the “should we build our own vault?” question.

What to read next: Vault & tokens · Hosted checkout-as-a-service · Operational guardrails.

SAQ A now (rented vault)

Today’s posture is SAQ A — the lightest self-assessment, available because Loop does not store, process, or transmit raw card data in its own systems. The card is tokenized client-side into a rented, exportable vault (Basis Theory), and Loop handles only tokens.

The hosted checkout-as-a-service design is what makes this hold across the whole ecosystem: the card only ever meets the Loop-hosted surface + the vault, so PCI scope collapses to one CDE and every consuming app stays entirely out of scope.

The growth path: SAQ D / own CDE (trigger-gated)

ADR-0093 rejected building a PCI CDE now (Option D — 6–12 months and six figures/year before shipping value) but preserved it as a destination, not a start. The own-CDE posture (LoopVault, SAQ D) is a later implementation of the same TokenVault interface — addressed by a different vaultId — not a re-architecture.

Validation Level vs SAQ are different axes. Transaction volume forces the validation Level (a Level 1 ROC per entity over time); it does not force storing raw PANs. Large players are typically Level 1 by volume while tokenized. So “be like Hims” is a Level question, not a raw-PAN question. SAQ D / own-CDE is reserved for the deplatforming-insurance trigger, not for competitor-matching.

What would trigger SAQ D

The own CDE is insurance against losing the rented vault — if a vault vendor froze or dropped Loop (the same deplatforming risk that applies to processors). It is gated, not scheduled. Until then, ADR-0093 says: for an entity with a direct acquiring relationship, prefer a proxy-vault (VGS) that forwards detokenized data to arbitrary endpoints while staying SAQ A, before concluding raw-PAN / SAQ D is required.

The rules that keep the option open (no rewrite)

The reason SAQ D is a capability and not a rewrite is that the foundation was built to a set of rules from day one:

Rule	Why it preserves the SAQ-D option
1. Vault-agnostic token refs `{ vaultId, tokenRef }`	Two vaults can run during a migration; `LoopVault` is just another `vaultId`.
2. Network tokens from the start	Card-on-file survives the vault swap.
3. Exportable vault only	A non-exportable vault would strand the book of business — own-CDE migration would be impossible.
4. Draw the CDE boundary now, even while rented	The boundary is already where it needs to be; SAQ D moves the implementation, not the boundary.
5. Treat deplatforming as routine	Health monitoring, auto-failover, and a re-vault runbook make a vault swap operational, not heroic.
6. Own the TRID (v2)	Network tokens port across acquirers regardless of vault — see Vault & tokens.

The phased PCI path

From ADR-0093’s phasing:

Phase A — thin slice on SAQ A: prove the abstraction + recon-ready data. (In review.)
Phase B — exportable, high-risk-confirmed vault + network tokens (Loop-owned TRID); validate cross-acquirer portability. (Planned.)
Phase B-ROC — scope-minimized Level 1 ROC, in parallel, volume-triggered. (Planned.)
Phase D — own CDE (SAQ D), the unchanged destination, trigger-gated. (Planned / gated.)

⚠️

Don’t round up the posture. Loop is SAQ A and the foundation is inert. None of the growth-path phases are in progress; they are explicitly trigger- and volume-gated. The value of the design is that reaching SAQ D later costs an implementation, not a rewrite — not that SAQ D is near.

Source

ADR-0093 — Unified Payment Orchestration & SAQ-D growth path (the SAQ-D growth path is in the title for a reason)

Card migration Operational guardrails