Regulatory compliance in financial services is built on auditability: the ability of a regulator to inspect, after the fact, the data and decisions that produced a given outcome. Fraud detection decisions — the approval or rejection of a transaction, the flagging of a behavioral anomaly — must be auditable to satisfy consumer protection mandates and institutional risk management obligations. Simultaneously, privacy law imposes the opposite requirement: data minimization, purpose limitation, and access restriction.

The data that makes fraud detection auditable — raw behavioral signals, device fingerprints, transaction metadata — is precisely the data that privacy law seeks to protect from broad access and long-term retention. Traditional fraud analytics resolve this tension by choosing one side: either retaining everything (creating liability) or aggressively purging (destroying audit evidence). QUORUM resolves the paradox structurally through a cryptographic architecture that produces audit evidence legally sufficient for compliance purposes without requiring raw data retention beyond operational necessity.

This document describes the complete cryptographic trust stack that delivers on this mandate: a Groth16 zero-knowledge proof engine backed by a Circom circuit, a post-quantum Dilithium3 signing layer compiled from Rust to WebAssembly, a fully homomorphic encryption federated learning protocol, a Merkle-tree hardened WORM audit ledger protected by Redis distributed locks, and an HSM abstraction layer providing AES-256-GCM envelope encryption with HKDF-SHA512 key derivation. Each component is described in terms of its production implementation — the actual code, the actual cryptographic parameters, and the actual behavior under real conditions.

At the heart of QUORUM's compliance architecture is a real zero-knowledge proof engine built on snarkjs and the Groth16 proving system. For every compliance-relevant decision — transaction verdicts, KYC evaluations, risk threshold crossings — QUORUM generates a Groth16 proof that cryptographically attests to the correctness of the computation without revealing the private inputs that informed it.

The proof generation pipeline uses three SHA-256 hashes as public signals: an orgIdHash binding the proof to the issuing organization, a verdictHash committing to the exact decision rendered, and a telemetryHash encoding the behavioral and financial signals that produced the risk score. These three values enter the ZKP engine as BigInt representations of their 256-bit SHA-256 digests.

The underlying arithmetic circuit is a Circom 2.0 template named KnowledgeOfSecret. The circuit accepts a single private input — secret — and produces a two-element public output array publicHash[2] computed via the circomlib SHA256 component. The fundamental property being proven is: the prover knows a secret value whose SHA-256 hash matches the committed public output, without revealing what the secret is.

// src/zkp/circuit.circom — KnowledgeOfSecret circuit
pragma circom 2.0.0;
include "circomlib/sha256/sha256.circom";

template KnowledgeOfSecret() {
    signal private input secret;
    signal output publicHash[2];

    component hasher = Sha256(256);
    for (var i = 0; i < 256; i++) {
        hasher.in[i] <== (secret >> i) & 1;
    }
    publicHash[0] <== hasher.out[0];
    publicHash[1] <== hasher.out[1];
}

component main = KnowledgeOfSecret();

The proof is generated via snarkjs.groth16.fullProve(input, wasmPath, zkeyPath), passing the three public commitment hashes as the circuit input. The resulting proof object and public signals are serialized and stored alongside the compliance record in the WORM audit ledger, creating an unforgeable cryptographic link between the decision outcome and the inputs that produced it.

In deployment environments where the Circom circuit artifacts (.wasm and .zkey files) have not yet been compiled, QUORUM automatically falls back to a SHA-256 HMAC commitment scheme. This fallback is not a degradation — it preserves the two most critical properties of the ZKP system: binding (the commitment cryptographically locks the decision to its inputs) and non-repudiation (the HMAC key is held in HashiCorp Vault, making the commitment impossible to forge without key access).

The fallback constructs a 32-byte HMAC-SHA256 commitment over the concatenation of all three input hashes, keyed against the LEDGER_HMAC_KEY retrieved from Vault. This commitment is indistinguishable in audit records from a ZKP proof commitment — both serve as cryptographic witnesses to the decision inputs. The system logs which mechanism was used, allowing auditors to identify records produced under each protocol.

Every compliance-relevant event in QUORUM is written to an immutable, append-only WORM audit ledger with three integrity layers: KZG polynomial commitments for O(1) inclusion proofs, post-quantum ML-DSA-65 HSM signing per entry, and FROST(Ed25519) threshold co-signature for final verdicts. The ledger is Write-Once, Read-Many: entries are immutable once committed. Inclusion is verifiable by any party holding the KZG commitment parameters — no trusted audit server required.

Each audit entry is committed as a KZG polynomial proof: the entry's content is encoded as evaluation points on a polynomial over the BLS12-381 scalar field, and the commitment is stored as a 48-byte G1 point. Inclusion proofs require two pairing operations to verify — e(proof, [τ − z]₂) = e(commitment − [f(z)]₁, G₂) — without traversing any tree structure. This replaces the previous O(log N) Merkle path traversal with O(1) constant-time verification regardless of ledger size.

The KZG scheme uses a structured reference string (SRS) established during the trusted setup phase. The SRS is shared with all participating institutions at deployment time, enabling independent offline verification of any audit entry without querying QUORUM infrastructure. A regulator with the SRS and a KZG proof can verify entry inclusion in under one millisecond — against a 48-byte commitment rather than a multi-megabyte Merkle tree.

The compliance healer runs a continuous KZG commitment consistency scan. If any stored commitment fails to verify against its entry content, the healer logs a critical security event and flags the specific entry for forensic investigation. Tampering is detected within the next scan cycle without human intervention.

Concurrent audit log appends and the transition from volatile event queues to durable storage are handled by a Postgres Write-Ahead Log (WAL) based event buffer using FOR UPDATE SKIP LOCKED. This eliminates the previous dependency on Redis for distributed locking: the WAL provides crash-consistent ordering guarantees at the database level, and the SKIP LOCKED pattern ensures workers claim events exclusively without contention or deadlock.

-- Claim next unprocessed audit event, skip locked rows
SELECT * FROM audit_event_queue
WHERE status = 'pending'
ORDER BY created_at
LIMIT 1
FOR UPDATE SKIP LOCKED;

-- On commit: WAL records the claim atomically
-- On worker failure: transaction rolls back, row becomes claimable again
-- No explicit lock TTL management required

The WAL-based approach provides stronger durability than Redis: committed events survive process crashes, host restarts, and network partitions without data loss, because the WAL is flushed to disk before the transaction is acknowledged. This ensures that every audit entry that reaches the commitment pipeline has a durable record regardless of downstream failures.

Every audit log entry is cryptographically signed using ML-DSA-65, the NIST-standardized post-quantum digital signature algorithm (FIPS 204, formerly Dilithium3). This is not a future roadmap item — it is the production implementation, compiled from Rust to WebAssembly using the fips204 crate and loaded at runtime by the Node.js process through a wasm-pq-crypto module.

ML-DSA-65 provides 128-bit quantum security — resistant to attacks from both classical and quantum computers, including Shor's algorithm which breaks RSA and ECDSA. The key sizes and signature sizes are fixed by the standard: 1,952-byte public keys, 4,032-byte secret keys, and 3,309-byte signatures. These parameters are enforced at the byte-array level in the Rust implementation, with explicit length validation before any cryptographic operation.

// Rust (wasm_pq_crypto) — ML-DSA-65 sign operation
pub fn sign(message: &[u8], sk_bytes: &[u8]) -> Result<Vec<u8>, JsValue> {
    let sk_array: [u8; 4032] = sk_bytes.try_into()
        .map_err(|_| JsValue::from_str("Invalid secret key length"))?;
    let sk = ml_dsa_65::PrivateKey::try_from_bytes(sk_array)
        .map_err(|_| JsValue::from_str("Invalid secret key data"))?;
    let sig = sk.try_sign(message, &[])
        .map_err(|_| JsValue::from_str("Sign failed"))?;
    Ok(sig.to_vec())
}

Signatures are stored in audit log entries using a compact encoding: mldsa65:{pkHex}:{sigHex}. This encoding carries the public key alongside the signature, enabling offline verification without requiring access to a central key registry. Any auditor with the public key can independently verify the authenticity of any audit log entry at any future time, including after a potential cryptopocalypse that breaks current asymmetric schemes.

All audit verdicts and governance actions in QUORUM are signed using FROST(Ed25519) — Flexible Round-Optimized Schnorr Threshold Signatures. FROST implements (t,n) threshold signing: a minimum of t participants (out of n co-signers) must contribute their partial signature for a valid aggregate signature to be produced. No single key compromise — of any one participant — can forge a signature. This provides a stronger security guarantee than single-key HSM signing for high-stakes audit attestations.

In QUORUM's deployment, the signing committee consists of the QUORUM audit node and designated institutional signing officers. For standard audit entries, a threshold of t=2 from n=3 participants suffices. For sovereign override events and rule promotions, the threshold is raised to t=3 from n=3 — requiring unanimous participation. The partial signatures are aggregated off-chain using the FROST two-round protocol; the resulting aggregate signature is indistinguishable from a standard Ed25519 signature, making it verifiable with any standard Ed25519 library.

In on-premise and hybrid deployments, the institution holds one or more FROST partial signing keys for their deployment. This means the institution is a required co-signer for all audit verdicts generated by their QUORUM instance. An audit entry cannot be forged without the institution's partial key — even by QUORUM infrastructure operators. The institution's FROST partial key is generated in-ceremony at onboarding and never transmitted to or stored by KB Analytical Solutions.

QUORUM's federated learning infrastructure replaces the previous FHE-based aggregation model with a more operationally efficient and cryptographically rigorous architecture: pairwise X25519 ECDH masking combined with mandatory local differential privacy. This architecture provides stronger privacy guarantees than central DP (the server never sees raw gradients), at substantially lower computational overhead than fully homomorphic encryption.

Before submitting gradient updates, each pair of participating institutions establishes a shared secret via X25519 Diffie-Hellman key exchange. Institution i generates a random mask r_{ij} from the shared secret with institution j (using HKDF-SHA256 with round number as context), adding r_{ij} to their gradient and subtracting r_{ij} from j's gradient before submission. The masks cancel exactly at the aggregation server — the server computes the sum of all masked gradients, which equals the sum of all unmasked gradients. The server never has access to the individual unmasked gradients or to any individual mask.

// Pairwise mask construction for institution i with partner j
const sharedSecret = x25519(privateKey_i, publicKey_j);
const mask_ij = HKDF(sharedSecret, salt=roundNumber, info="gradient_mask");

// Gradient submission: add mask for partners where i < j, subtract where i > j
// Masks cancel at aggregation: Σ maskedGradient = Σ rawGradient
// Server never sees any individual rawGradient or any individual mask

Before applying pairwise masks, each institution applies mandatory local differential privacy to their gradient: a clipping step bounds the L2 norm of the gradient (ensuring bounded sensitivity), followed by addition of calibrated Gaussian noise with standard deviation σ determined by the privacy budget. The server verifies that submitted gradients satisfy the declared noise calibration parameters before accepting them — institutions cannot bypass local DP by submitting raw gradients.

Privacy budget consumption is tracked using a Rényi differential privacy (RDP) moments accountant, which provides tight composition bounds across multiple training rounds. The accountant converts the RDP budget to (ε, δ)-DP guarantees at any specified δ. After each training round, the accountant produces an HSM-signed privacy certificate: a structured artifact stating the round number, noise parameters, composition bound, and achieved (ε, δ) values — signed by the institution's HSM key.

QUORUM's secret management architecture centers on a SecureSecretsContainer — a private, non-enumerable JavaScript Map that is loaded at process startup from HashiCorp Vault and never injected into process.env. This design prevents the most common secret exfiltration attack vector in Node.js applications: environment variable leakage through error reporting tools, diagnostic endpoints, or process inspection.

The container's Map is declared with Object.defineProperty using enumerable: false and configurable: false, preventing it from appearing in object key iteration, JSON serialization of the parent object, or Object.keys() calls. The only access path is through the get(key) method, which is the single controlled interface.

All environment variables declared in the Zod configuration schema are sourced from Vault first, with process.env as a fallback only for development environments where Vault may not be available. The configuration schema itself is validated using Zod at process startup, with strict type enforcement and minimum-length requirements on all secret values. Invalid configuration causes immediate process termination rather than silent degradation.

The configuration object is exported as a Proxy that defers the actual getConfig() call until a property is first accessed. This allows external secret loaders — such as Vault's dynamic secret lease renewal — to update values between configuration accesses without requiring a process restart.

All PII fields — email addresses, phone numbers, card numbers, and sensitive identity data — are encrypted at rest using AES-256-GCM envelope encryption. The envelope encryption design generates a unique Data Encryption Key (DEK) for each encryption operation, which is itself encrypted under a Master Encryption Key (MEK) derived from the HSM. This two-level key hierarchy means that MEK rotation does not require re-encryption of historical data — only the DEK ciphertexts need to be re-wrapped.

The MEK is derived via HKDF-SHA512 from the HSM-provided key material, using a domain-specific salt to prevent cross-context key reuse. QUORUM's HSM abstraction layer supports two backend implementations: AWS KMS as the primary HSM for cloud deployments, and a local TPM-backed fallback for on-premises institutional deployments where cloud connectivity cannot be guaranteed.

The AES-256-GCM implementation generates a fresh 12-byte initialization vector for each encryption operation. The resulting ciphertext is stored as a colon-delimited string: {iv_hex}:{ciphertext_hex}:{authTag_hex}. The authentication tag provides authenticated encryption — any tampering with the ciphertext is detected at decryption time before any plaintext is produced.

Encrypted fields in the database schema follow a dual-storage pattern: the raw ciphertext is stored in an encrypted_* column, while a deterministic SHA-256 hash of the plaintext is stored in a *_hash column. This allows equality lookups (e.g., finding a user by email hash) without requiring decryption, preserving both security and query performance.

Before any behavioral signal or identity context is transmitted to external intelligence services — including the Gemini dark web sensor, OSINT Scout, or cloud LLM endpoints — QUORUM passes the data through the Identity Shield, a deterministic PII anonymization layer that replaces all sensitive identifiers with irreversible pseudonymous tokens.

The anonymization uses HMAC-SHA256 keyed against an identity-specific key derived from the HSM. The derivation uses a fixed salt unique to the identity anonymization domain, ensuring that the key used for PII masking cannot be used to derive keys in any other QUORUM subsystem. The output of each HMAC operation is a deterministic pseudonym in the format quorum_entity_{first_16_hex_chars}.

// Deterministic, irreversible PII masking
export async function maskIdentity(plainText: string): Promise<string> {
  const key = await getIdentityKey(); // HSM-derived, cached
  const hash = crypto.createHmac("sha256", key)
                      .update(String(plainText))
                      .digest("hex");
  return `quorum_entity_${hash.slice(0, 16)}`;
}

The bleachTelemetry function recursively traverses any object and masks all fields matching the sensitive field list: userId, email, name, phoneNumber, accountNumber, address, and ip. Nested objects and arrays are traversed recursively. The pseudonymization is deterministic — the same plaintext always produces the same token — enabling AI pattern recognition across multiple events involving the same identity without the AI system ever holding the real identifier.

The identity key is cached after the first HSM derivation, eliminating the overhead of repeated HSM calls during high-volume processing. The key is stored only in memory and is never written to disk, logs, or any persistent store outside the HSM itself.

QUORUM's institutional API access model uses an Atomic Verification Protocol — a quantum-inspired state collapse pattern where the verification challenge can be observed exactly once before it becomes invalid. This is implemented using Redis Lua scripting to provide transactional atomicity at the key-value level, eliminating race conditions in challenge issuance and consumption.

The protocol operates in three stages: generate (issue a challenge state with a 30-second TTL), measure (atomic observe-once — the state collapses on first read, preventing replay), and verify handshake (HMAC-based timing-safe comparison against the expected response).

The HMAC key for handshake verification is stored in HashiCorp Vault as ATOMIC_HMAC_KEY. The constant-time comparison prevents an adversary from learning the correct HMAC value through timing side-channels — a classical attack against naive string equality implementations in authentication systems. The 30-second TTL ensures challenges cannot be stockpiled for future replay attacks.

QUORUM's sanctions screening architecture combines a Verifiable Oblivious Pseudorandom Function (VOPRF) Private Set Intersection (PSI) protocol — implemented over the Ristretto255 prime-order group — with local fuzzy matching. The privacy guarantee is explicit: the screening service learns only that some entity was queried. The name or identifier being screened is never transmitted in cleartext to any external endpoint. This resolves a structural data minimization problem in traditional sanctions screening, where the screened name must be disclosed to the screening service to perform a lookup.

QUORUM maintains local copies of the OFAC SDN List and the UN Consolidated Sanctions List, fetched as XML, parsed in-process, and refreshed every 20 hours — ensuring local cache staleness never exceeds 4 hours in a 24-hour window. The VOPRF protocol blinds the queried name client-side before the lookup against the local list, and the blinded query is evaluated against the blinded list entries. The server evaluates the blinded name and returns a blinded result; the client unblinds the result to determine membership. At no point does the name appear in cleartext outside the institution's own process boundary.

The VOPRF protocol uses Ristretto255 for group operations, which provides a prime-order group abstraction over Curve25519, eliminating cofactor-related vulnerabilities present in raw Edwards25519 operations. The blinding step computes r · H(name) where r is a uniformly random scalar and H is a hash-to-curve function mapping the name to a Ristretto255 point. The server evaluates the OPRF using its secret key k, returning k · (r · H(name)). The client unblinds by computing r⁻¹ · (k · r · H(name)) = k · H(name) and checks this value against a precomputed table of OPRF outputs for all sanctions list entries.

For regulatory completeness, QUORUM also performs local Levenshtein fuzzy matching against normalized sanctions list entries — names are normalized by stripping legal suffixes and honorific prefixes before comparison. VOPRF PSI handles exact membership; fuzzy matching handles transliteration variants and near-match detection. Both produce a confidence score and action directive.

Every screening result — both hits and clears — is recorded in the sanctions_hits table with full indexing on organizationId, userId, matchedList, confidence, action, and createdAt. This creates a complete, timestamped audit trail of every entity screened, satisfying AML record-keeping requirements without relying on external screening service logs.

For individuals, the screening checks both the primary name and any aliases (a.k.a. entries) associated with the sanctions record. For entities, the screening checks all listed names and program-specific identifiers. The engine supports screening against either list independently or both simultaneously, with results tagged by source list for regulatory reporting purposes.

For institutional deployment contexts that interface with SWIFT and SEPA payment networks, QUORUM provides an ISO 20022 message mapping layer that translates internal fraud verdicts into standard payment status notification formats. This allows QUORUM's risk decisions to flow directly into institutional payment infrastructure without requiring custom integration work.

QUORUM's ISO mapping service translates risk verdicts into three ISO 20022 rejection reason codes, used in pacs.002 (payment status report) and pacs.008 (financial institution credit transfer) message flows:

The mapping service generates a well-formed ISO 20022 XML fragment for each verdict, including the original end-to-end identification reference, the transaction ID, the group status (RJCT), and the specific reason code. This XML fragment can be embedded directly into the institution's outbound payment status messages, providing a standards-compliant paper trail of every rejection decision.

QUORUM includes an autonomous FINTRAC compliance gateway for Canadian institutional deployments. Transactions exceeding the CAD $10,000 threshold — the Large Cash Transaction (LCTR) reporting threshold under the Proceeds of Crime (Money Laundering) and Terrorist Financing Act — trigger an automatic compliance workflow without human intervention.

The LCTR workflow: (1) identifies the transaction as exceeding threshold, (2) generates a high-fidelity forensic compliance audit report with all available transaction context, (3) creates a proposed rule entry in the compliance record with the case reference, and (4) returns the FINTRAC report ID and PDF evidence path to the calling system for submission to the financial intelligence unit. The entire workflow is completed within the request lifecycle, ensuring no reportable transaction is processed without generating the required documentation.

QUORUM's financial transaction layer implements a cryptographically-hardened double-entry accounting ledger. Every balance movement — deposit, withdrawal, transfer, fee, adjustment — is recorded as a pair of ledger entries (debit and credit) in a hash-chained sequence. The OffsetLedger module manages chain integrity, computing a fresh SHA-256 hash for each entry that incorporates the account ID, amount, organization ID, and the hash of the immediately preceding entry for that account.

The chain is initialized with a sentinel value of GENESIS_BLOCK for the first entry in each account's history. This sentinel is human-readable in the database, making it immediately obvious when inspecting records that the chain originated cleanly without any prior state. Each entry also carries an HMAC-SHA512 signature of the entry hash, using the LEDGER_HMAC_KEY from Vault.

// Hash chain construction — each entry commits to its predecessor
const prevHash = lastEntry?.entryHash || "GENESIS_BLOCK";
const data = `${accountId}:${amount}:${prevHash}:${orgId}`;
const hash = crypto.createHmac("sha256", config.LEDGER_HMAC_KEY)
                   .update(data).digest("hex");

The verifyAccountIntegrity method traverses the complete entry history for any account in reverse chronological order, re-deriving each entry's expected hash and signature, and comparing against the stored values. A single mismatch — indicating either a tampered entry or a broken link in the chain — returns false and logs a critical security event identifying the specific entry at which chain integrity failed.

This cryptographic integrity verification is surfaced as an auditable compliance check: institutions can request an integrity proof for any account at any time, receiving a boolean result plus the entry ID of any detected anomaly. The result is itself written to the immutable audit log, creating a permanent record of when chain verification was performed and what it found.