PCI DSS 4.0 demands stronger protection for cardholder data. H33's fully homomorphic encryption lets your AI process card numbers, transaction amounts, and behavioral patterns without ever decrypting them. Compliance becomes architectural.
PCI DSS 4.0, effective March 2025, strengthens requirements for protecting cardholder data across every stage of the payment lifecycle. The standard introduces new mandates for cryptographic key management, continuous monitoring, and targeted risk analysis. These are meaningful improvements to payment security.
But AI fraud detection, transaction scoring, behavioral analytics, and real-time risk assessment all require access to cardholder data. Every time your AI model processes a primary account number, you create a compliance risk. The model needs plaintext to operate. Traditional encryption stops at the point of use — the moment computation begins, decryption must happen, and a window of exposure opens.
This tension between AI capability and data protection is the central challenge for any financial institution deploying machine learning on payment data. You cannot run a fraud model on an encrypted card number with traditional cryptography. Until now, the choice was: AI insight or data protection. H33 eliminates that tradeoff.
PCI DSS 4.0 organizes its 12 requirements into six control objectives. For AI systems processing cardholder data, four requirements are critical:
Requirement 3: Protect stored account data. PANs must be rendered unreadable anywhere they are stored. Encryption, truncation, masking, and hashing are all acceptable — but the standard assumes data is decrypted for processing.
Requirement 4: Protect cardholder data with strong cryptography during transmission. Data in transit must be encrypted using strong protocols. This covers network transfers but not in-memory computation.
Requirement 6: Develop and maintain secure systems and software. Secure coding practices, vulnerability management, and change control. AI models introduce new attack surfaces not covered by traditional SDLC practices.
Requirement 10: Log and monitor all access to system components and cardholder data. Every access must be recorded, and audit trails must be protected from tampering.
The gap: no PCI DSS requirement explicitly covers encryption during computation. Data is protected at rest (Req 3) and in transit (Req 4), but the standard assumes plaintext processing is inevitable. H33 fills this gap by eliminating plaintext processing entirely.
H33's fully homomorphic encryption processes card numbers, transaction amounts, merchant codes, and behavioral patterns while they remain encrypted. The data is never decrypted on any server at any point during AI processing.
Your fraud detection model scores transactions on ciphertext. It computes risk assessments, anomaly detection, and behavioral matching without ever seeing a plaintext card number. The result is an encrypted match score — decrypted only by the authorized party holding the decryption key. H33's infrastructure never possesses that key.
This is not tokenization, which substitutes a placeholder value. It is not masking, which hides portions of the PAN. It is computation on encrypted data using the BFV lattice-based encryption scheme, where the security guarantee is mathematical and does not depend on access controls, network segmentation, or human processes. A breach of the processing server exposes ciphertext that is computationally indistinguishable from random noise.
Cardholder data never exists in plaintext in H33's infrastructure. Not in RAM. Not in logs. Not in swap files. Not in crash dumps. The CDE scope shrinks to your own endpoints — H33's servers are out of scope because they never process plaintext cardholder data.
A single API call. Six cryptographic operations. Zero plaintext exposure.
Transaction data is encrypted at the point of capture using BFV FHE. It is transmitted over post-quantum TLS via ML-KEM key exchange. FraudShield processes the encrypted transaction — scoring risk, detecting anomalies, and matching behavioral patterns — all on ciphertext. A ZK-STARK proof is generated to verify compliant processing without revealing the data. A Dilithium signature attests to the entire operation. The encrypted result is returned to the authorized party, who holds the only decryption key.
How H33 maps to specific PCI DSS 4.0 requirements.
| PCI DSS Req | Requirement | H33 Coverage |
|---|---|---|
| 3.4.1 | Render PAN unreadable | FHE — PAN encrypted throughout, including during AI processing. Ciphertext is indistinguishable from random noise. No plaintext exists at any point. |
| 3.5.1 | Restrict access to cryptographic keys | Dilithium key management with threshold signing via H33-MPC. Key material is never stored on processing servers. Post-quantum key exchange for all key transport operations. |
| 4.2.1 | Strong cryptography for transmission | ML-KEM (Kyber) key exchange with post-quantum TLS. NIST FIPS 203 compliant. Forward secrecy maintained even against future quantum adversaries. |
| 6.2.4 | Software development security | ZK-STARK proof of compliant code execution. Every processing step is cryptographically verified. Tamper-evident by construction — no way to execute unauthorized logic without invalidating the proof. |
| 10.2.1 | Audit trail for all access | Dilithium-signed audit logs with 30-year retention. Every access, computation, and key operation is recorded. Append-only log structure with SHA3-256 chain hashing. |
| 10.3.1 | Protect audit trails from tampering | Post-quantum Dilithium signatures on every log entry. On-chain Merkle anchoring provides independent tamper evidence. Auditors verify signatures without trusting the log host. |
Purpose-built modules for financial institutions, each backed by FHE and post-quantum cryptography.
AI fraud detection that never sees cardholder data. Scores transactions on ciphertext using FHE. Real-time risk assessment at 38.5µs per operation. Zero plaintext exposure means zero PCI scope expansion.
Learn moreCross-bank fraud intelligence sharing without exposing customer data. Each institution contributes encrypted signals. The aggregated model trains on ciphertext. No bank sees another bank's cardholder data.
Learn morePost-quantum key management for financial infrastructure. Dilithium-signed key rotation, hardware-backed key storage, and threshold key splitting via MPC. Meets PCI DSS 3.5.1 key access controls.
Learn morePost-quantum API gateway for payment processing. ML-KEM key exchange, Dilithium-signed requests, and FHE-encrypted payloads. Drop-in replacement for traditional TLS gateways with quantum-safe protection.
Learn moreIndependent third-party audit of security, availability, and confidentiality controls. 114+ controls monitored continuously through Drata. Evidence collected automatically.
For financial institutions handling health payment data. All 18 PHI identifiers encrypted with Kyber-1024. Business Associate Agreement available at all tiers.
ML-KEM (Kyber) for key encapsulation and ML-DSA (Dilithium) for digital signatures. Both NIST post-quantum standards, finalized August 2024. Production-deployed.
Dilithium-signed, append-only audit logs with on-chain Merkle anchoring. Exceeds PCI DSS 10.7.1 minimum retention. Every operation independently verifiable decades later.
FHE, zero-knowledge proofs, and Dilithium signatures execute in a single API call. No GPU required. ARM CPU only.
FHE-encrypted payment processing, post-quantum audit trails, and PCI DSS 4.0 requirements mapping. Run AI on financial data without creating compliance risk.