Issuer
Merchant / payment issuer
The merchant or payment issuer binds its payment-compliance claim locally before producing the proof.
Illustrative ZK disclosure scenario · Not a PCI DSS certification
PCI DSS / ZK credential
Payment compliance, proven without the cardholder data
An illustrative ZK payment-compliance proof lets a merchant or payment issuer attest to a scoped cardholder-data environment without disclosing the PAN, CVV, or the underlying cardholder record to an acquirer or payment partner.
Scope note: Illustrative scenario only. It shows a possible proof shape for partner discussion; it is not a PCI DSS certification, legal advice, or a compliance determination.
Concrete ZK disclosure scenario
Payment compliance, proven at the CDE boundary
The merchant or payment issuer holds cardholder data and the detailed CDE witness as the private witness. The proof carries only the public facts an acquirer or payment partner needs to verify a scoped payment-compliance claim.
Private witness
PAN + CVV + full track data + CDE witness
PAN, CVV, full track data, tokenization and key-custody evidence, logging records, and the detailed CDE witness stay inside the merchant/payment issuer boundary; no cardholder data enters the proof envelope.
Public statement
payment_compliance = valid
payment_processing · attested_cde_scope
Public proof envelope
Expiry-bound, revocable payment-compliance proof envelopepolicy =
Published PCI DSS CDE scope policypolicy_hash =
0x9d31…4af0
claim_type
payment_compliance
claim_purpose
payment_processing
claim_class
attested_cde_scope
cde_scope
scoped / attested
tokenization
attested
key_custody
attested
logging_posture
attested
policy_hash
0x9d31…4af0
expiry
bounded validity window
revocation_state
unrevoked / re-checkable
proof_validity
true
Verification result
Acquirer / payment partner
valid = true · policy_hash matched · disclosure_boundary = sealed
The acquirer or payment partner re-checks the proof against the published PCI DSS scope policy hash and current revocation state. The merchant’s cardholder-data witness is never returned with the decision.
Issuer → partner narrative
Bind locally. Verify remotely.
The merchant or payment issuer seals the PAN, CVV, full track data, tokenization and key-custody evidence, logging records, and detailed CDE witness inside its boundary. It sends the acquirer or payment partner only the proof and the minimum public claim fields needed to verify payment compliance; the underlying cardholder data never leaves the issuer boundary.
Wire shape
proof + minimum public claim fields
The disclosure boundary
The verifier gets a payment decision, not the card data.
What the verifier learns
Scoped payment-compliance outputs
The acquirer or payment partner learns that a payment_compliance claim is valid for payment_processing and the defined CDE scope, with tokenization, key custody, and logging posture attested against the published policy hash within its expiry and revocation rules. It can verify the proof without receiving cardholder data.
What remains sealed
No cardholder data crosses the partner boundary
PAN, CVV, full track data, tokenization and key-custody evidence, detailed CDE witness, and the underlying payment records remain sealed inside the merchant or payment issuer boundary.
Credential type
A ZK credential for an attested CDE scope.
ZK
cardholder_scope_v2
A zero-knowledge credential lets a merchant or payment issuer prove a scoped payment-compliance claim against a published PCI DSS CDE scope policy hash. The proof exposes the attested handling posture without turning the acquirer or payment partner into a cardholder-data relay. See the PrivacyCore™ agent identity explainer for the underlying privacy-rail primitive, and read the FHE workflow for sensitive agent-side computation over regulated inputs.
Partner POC
Make the regulated claim verifiable, not visible.
Use the partner spec to map the issuer boundary, public policy fields, and verification flow for your own regulated workflow.
← Back to Regulated Verticals