Compliance

PQSafe AgentPay was designed from the ground up for regulated environments. This page summarizes the relevant standards and how PQSafe addresses each.

FIPS 204 (ML-DSA)

NIST FIPS 204 is the US federal standard for ML-DSA (Module Lattice Digital Signature Algorithm), finalized in August 2024. It standardizes three parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87.

PQSafe uses ML-DSA-65 (security level 3, equivalent to AES-192):

Requirement	PQSafe implementation
FIPS 204 compliant algorithm	ML-DSA-65 via @noble/post-quantum (pure JS, no native deps)
Deterministic serialization	JCS / RFC 8785 canonical JSON before signing
Key size	Secret key: 4,032 bytes · Public key: 1,952 bytes
Signature size	3,293 bytes (6,586 hex chars)

The signature algorithm is quantum-computer-resistant. Classical attacks require brute force against module lattice problems; no quantum speedup is known.

Note

FIPS 204 compliance applies to the cryptographic primitive. For US federal agency use, additional key management requirements (FIPS 140-3 validated HSM for key storage) may apply. PQSafe’s key generation and signing are compatible with FIPS 140-3 HSM integration via standard PKCS#11 interfaces.

Further reading: NIST FIPS 204 (PDF)

---

HKMA QPI (Quantum-safe Payment Infrastructure)

The Hong Kong Monetary Authority (HKMA) issued the Quantum-safe Payment Infrastructure (QPI) circular in 2023, requiring licensed banks and payment service providers in Hong Kong to develop quantum-safe migration roadmaps.

Key QPI requirements and how PQSafe addresses them:

QPI requirement	PQSafe implementation
Quantum-resistant authorization for high-value transactions	ML-DSA-65 on all spend envelopes, regardless of amount
Audit trail for AI-initiated payments	Immutable append-only ledger with hash chain integrity
Human-in-the-loop controls	Configurable approval gate (Telegram/Slack/webhook)
Revocation mechanism	revoke() function + revocation service check on every payment
Key rotation policy	rotateSpendKey() + createAgentSubkey() for scoped delegation

PQSafe is designed to help Hong Kong-licensed payment institutions meet QPI readiness requirements for agentic payment infrastructure.

Further reading: HKMA QPI Circular (hkma.gov.hk)

---

EU DORA (Digital Operational Resilience Act)

EU DORA (Regulation 2022/2554) applies to financial entities operating in the EU, including payment institutions, crypto-asset service providers, and their critical ICT third-party providers. DORA became applicable on 17 January 2025.

DORA is primarily an ICT risk management framework. For agentic payment systems, the most relevant requirements are:

DORA requirement	PQSafe implementation
ICT risk management — systems must be resilient against cyber threats	ML-DSA-65 is resistant to both classical and quantum adversaries
Audit logging — all ICT operations must be logged	Immutable ledger with cryptographic hash chain; on-chain anchoring available
Change management — authorization must be documented	Every payment is bound to a signed envelope with issuer identity and purpose
Third-party risk — critical ICT suppliers must meet standards	PQSafe is a pure SDK (no mandatory cloud dependency); on-prem deployment supported
Incident response — ability to detect and respond to anomalies	Spend envelope bounds provide automatic anomaly prevention; revocation available

Caution

DORA compliance is holistic — it covers processes, governance, and testing in addition to technical controls. PQSafe addresses the technical authorization and audit trail layer. Your legal and compliance team should assess the full DORA applicability and gap analysis for your institution.

Further reading: EU DORA text (EUR-Lex)

---

Audit trail

Every payment attempt generates an immutable ledger record containing:

• Envelope ID (SHA-256 of canonical envelope JSON)
• Agent ID
• Recipient
• Amount and currency
• Rail used
• Outcome (settled / failed / rejected)
• ML-DSA-65 signature fingerprint
• Timestamps (submitted, settled)
• Optional: Arbitrum on-chain anchor transaction hash

The ledger uses a hash chain: each entry includes the hash of the previous entry, making retroactive tampering detectable. For regulated contexts, use commitEnvelopeToArbitrum() to anchor the payment proof on-chain.

---

Key management recommendations

Context	Recommendation
Development	.env file (gitignored)
CI/CD	GitHub Actions Secrets / environment variable
Production (cloud)	AWS Secrets Manager, GCP Secret Manager, Azure Key Vault
Production (regulated)	FIPS 140-3 validated HSM (Thales, AWS CloudHSM, Azure Dedicated HSM)
Key rotation	Use rotateSpendKey() on a scheduled basis; old key is revoked

The ML-DSA-65 secret key is 4,032 bytes. Treat it with the same care as a signing key for a payment authorization system — because that is exactly what it is.