NIST Post-Quantum Audit Trails for Banking

Every wire transfer your bank processes today generates a log entry. Every loan approval, every fraud flag, every compliance decision, every BSA/AML screening result — all of it goes into an audit trail that regulators expect to remain intact for seven years minimum. Some categories require ten. Some require permanent retention. The entire regulatory apparatus of modern banking — OCC examinations, Fed supervisory reviews, FDIC assessments, state banking department audits — rests on the assumption that these audit trails are trustworthy. That what was recorded is what actually happened. That no one altered the record between the time of the decision and the time of the examination.

That assumption is about to break.

Not today. Not next quarter. But within the retention window of records being created right now. A wire transfer approved this morning and logged with an RSA-2048 digital signature has a seven-year retention requirement. In seven years, a sufficiently capable quantum computer running Shor's algorithm can forge that RSA-2048 signature in polynomial time. The audit trail that your compliance team relies on — the one that proves the wire was authorized by a specific officer at a specific time with specific supporting documentation — becomes cryptographically worthless. Not because someone hacked your systems. Because the mathematics your signatures depend on stopped being hard.

This is not a theoretical concern. It is the specific threat model that NIST spent eight years and three rounds of public cryptanalysis addressing. The result is three finalized post-quantum signature standards: FIPS 204 (ML-DSA, formerly Dilithium), FIPS 205 (SLH-DSA, formerly SPHINCS+), and FIPS 206 (FN-DSA, based on FALCON-512). These are not draft proposals. They are finalized federal information processing standards with assigned FIPS numbers, published parameter sets, and reference implementations. The transition from classical to post-quantum signatures is not a question of if. It is a question of when — and for banking audit trails, "when" means now, because the records you sign today need to survive verification attempts seven to ten years from now.

The harvest-now-decrypt-later threat to audit integrity

The intelligence community has a name for the attack pattern that makes this urgent: harvest now, decrypt later. A nation-state adversary — or a sophisticated criminal organization, or a rogue insider with access to backup tapes — captures signed audit records today, while they are cryptographically protected by classical signatures. They store those records. They wait. When quantum computing reaches sufficient scale, they use Shor's algorithm to forge the signatures on those records, creating alternative audit trails that show different decisions, different authorizations, different compliance outcomes. The forged records are cryptographically indistinguishable from the originals because the signature scheme itself has been broken.

For banking, this threat is not about stealing money directly. It is about retroactive liability fabrication. Consider: a bank processes a wire transfer that later turns out to be connected to sanctions evasion. The bank's defense in an OCC enforcement action is the audit trail showing that proper screening was performed and the wire passed all controls at the time of processing. If an adversary can forge the signatures on those audit records, they can create an alternative trail showing that screening was skipped, or that red flags were suppressed, or that the authorizing officer was different from who actually approved it. The bank's defense evaporates — not because the bank did anything wrong, but because the cryptographic integrity of its evidence has been compromised.

This is not paranoia. This is the threat model that OMB Memorandum M-23-02 was written to address. It is the threat model that CNSA 2.0 specifically calls out. It is the reason that federal agencies have been given a 2030 deadline for post-quantum migration. And it is the reason that any bank with federal customers, federal deposits, or federal regulatory oversight needs to take the audit trail integrity problem seriously right now — not when quantum computers arrive, but while records are being created that will still be under retention when they do.

What OCC and Fed examiners actually verify

A bank examination is not a penetration test. Examiners do not try to hack your systems. What they do is request specific records and verify that those records are internally consistent, properly authorized, and complete. The OCC's Comptroller's Handbook on Information Technology is explicit about this: examination procedures include verifying that audit trails are "adequate, complete, and protected from unauthorized modification." The Fed's SR 05-23 guidance on information security requires that "audit trails and logging practices are sufficient to support after-the-fact investigation of security incidents and unauthorized activities."

Today, "protected from unauthorized modification" means HMAC signatures, RSA signatures, or database-level integrity checks. These are classical constructions. They work against classical adversaries. They do not work against quantum adversaries. When an examiner in 2033 asks for the audit trail of a 2026 wire transfer, and that trail is signed with RSA-2048, the examiner has to trust that no one with quantum computing access has tampered with the record. That trust is not cryptographic. It is operational. It depends on physical security, access controls, backup integrity, and the assumption that quantum computers are not yet available to the adversaries who might want to alter banking records.

Post-quantum signatures eliminate this trust dependency. A record signed with ML-DSA-65 today remains cryptographically verifiable against forgery even after quantum computers arrive. The examiner in 2033 does not need to trust your operational security practices from 2026. They can verify the signature directly. The mathematics is sufficient. This is a strictly stronger guarantee — it replaces an operational assumption (nobody with quantum access tampered with this) with a mathematical guarantee (nobody without the signing key could have produced this signature, quantum computer or not).

Why three signature families, not one

NIST finalized three distinct post-quantum signature standards because no single mathematical assumption has been tested against decades of cryptanalysis the way RSA's integer factoring assumption has. ML-DSA relies on the hardness of Module Learning With Errors over lattices. FALCON-512 relies on the hardness of the Short Integer Solution problem over NTRU lattices. SLH-DSA relies entirely on the collision resistance of hash functions. These are three independent mathematical bets. A breakthrough against one does not automatically compromise the others.

For banking audit trails that must survive seven to ten years of future cryptanalytic advances, single-family signatures are a single point of failure. If you sign all your audit records with ML-DSA alone, and a breakthrough against module lattices emerges in 2031, every record you signed becomes forgeable. Your entire audit trail — every wire transfer, every loan approval, every compliance decision from 2026 to 2031 — loses its cryptographic integrity simultaneously.

H33's approach is to sign every attestation with all three families simultaneously. The H33-74 substrate binds a computation result to a three-family signature bundle: ML-DSA-65 (FIPS 204), FALCON-512 (FIPS 206), and SLH-DSA-SHA2-128f (FIPS 205). To forge a substrate, an adversary must break all three mathematical assumptions simultaneously — module lattice problems, NTRU lattice problems, and hash function pre-image resistance. A breakthrough against any single family degrades the construction to two-family security, which is still stronger than any single-family alternative. This is assumption diversity, and it is the only responsible approach for records that need to survive an uncertain cryptanalytic future.

The 74-byte construction for banking

A natural concern with post-quantum signatures is size. ML-DSA-65 signatures are 3,293 bytes. FALCON-512 signatures are approximately 666 bytes. SLH-DSA-SHA2-128f signatures are 17,088 bytes. A three-family signature bundle totals approximately 21,000 bytes. For audit trails that may contain millions of records, this overhead matters.

H33-74 solves this with a two-layer architecture. The full signature bundle exists ephemerally during signing and verification. What persists — what goes into your audit database, your blockchain anchor, your long-term storage — is 74 bytes. A 32-byte SHA3-256 content hash binding the attested data. A 32-byte cryptographic commitment to the full signature bundle. Metadata (version, computation type, timestamp, nonce) filling the remaining 10 bytes. The persistent footprint is 74 bytes regardless of whether you are attesting a single wire transfer or a batch of ten thousand compliance decisions.

For banking specifically, this means the storage overhead of post-quantum audit trails is negligible. 74 bytes per attested event. A bank processing one million transactions per day adds 74 megabytes per day to its audit storage — less than a single surveillance camera frame. The post-quantum authentication infrastructure does not require a storage architecture redesign. It fits into existing database schemas, existing backup procedures, existing archival workflows.

How it works for a wire transfer

The concrete flow for a wire transfer attestation is straightforward. When a wire transfer is approved, the authorization system produces a canonical encoding of the decision: the transaction identifier, the authorizing officer, the timestamp, the amount, the screening results, the risk score, and any other fields required by the bank's retention policy. This canonical encoding is hashed with SHA3-256 to produce a 32-byte content hash. The content hash, along with a computation type byte identifying this as a financial transaction attestation, a millisecond timestamp, and a 16-byte nonce, forms the 58-byte substrate. The substrate is then signed by all three post-quantum signature families, producing the approximately 21KB signature bundle. A SHA3-256 hash of the concatenated bundle produces the 32-byte commitment in the 42-byte compact receipt. The persistent record is the 74-byte substrate-plus-receipt pair.

Verification works in reverse. Given the original canonical data, a verifier recomputes the SHA3-256 content hash and checks it against the substrate. Given the signature bundle, the verifier checks each of the three signatures against the signer's published public keys. Given the bundle, the verifier recomputes the SHA3-256 commitment and checks it against the compact receipt. If all checks pass, the verifier has mathematical proof that the specific canonical data was attested by the holder of the three-family signing keys at the recorded timestamp. No runtime dependency on H33 infrastructure. No API call needed. Pure cryptographic verification.

This is what distinguishes proof from logging. A log says "wire transfer WT-2026-04-20-001 was approved by Officer Smith at 14:32:07 UTC." A substrate proves it. The distinction matters because logs can be edited by anyone with database access. Substrates cannot be forged without simultaneously breaking three independent mathematical hardness assumptions.

Batch attestation for high-volume banking

Large banks process millions of events per day. Individual signing of each event at three-family post-quantum security would be computationally expensive — not prohibitively so, but enough to matter at scale. H33 addresses this with batched Merkle attestation (Patent pending — H33 substrate Claims 124-125).

Within a configurable time window — 60 seconds by default — individual event substrates are collected into a Merkle tree. The tree root is signed once with the three-family bundle. Each individual substrate gets a Merkle inclusion proof (O(log N) sibling hashes) that links it to the signed root. The result: one three-family signing operation per batch, regardless of batch size. At one million events per batch, the per-event signing cost is amortized to effectively zero. The per-event verification cost is 20 SHA3-256 hashes (the Merkle path) plus one three-family signature verification.

H33's production infrastructure processes 2,216,488 attestations per second on a single ARM server. This is not a theoretical throughput number. It is measured on production hardware running the full pipeline: FHE batch processing, three-family signing, and verification. For context, the entire Fedwire system processes approximately 800,000 transfers per day. H33 can attest that entire daily volume in under one second.

Integration with existing banking infrastructure

Banks do not rip and replace infrastructure. Any post-quantum audit trail solution that requires a new database, a new logging pipeline, a new archival system, or a new examination workflow is dead on arrival. H33 is designed as a drop-in attestation layer that sits alongside existing systems.

The integration pattern is an API call. When your existing authorization system logs a decision, it simultaneously calls the H33 attestation endpoint. The endpoint returns a 74-byte substrate. Your existing logging system stores the substrate alongside the existing log entry. Your existing backup system backs up both. Your existing archival system archives both. The only change is an additional 74 bytes per record and an API call that completes in under 26 milliseconds.

For banks that want on-premises deployment — and most regulated institutions do — H33 runs inside a Trusted Execution Environment on the bank's own hardware. The signing keys never leave the bank's infrastructure. No data is transmitted to H33 servers. The commercial license includes the attestation runtime, the verification tools, and the key management integration. The bank operates its own attestation infrastructure with no runtime dependency on any external service.

The regulatory alignment

The regulatory picture is unambiguous. OMB M-23-02 requires federal agencies to inventory their cryptographic systems and prepare migration plans to post-quantum algorithms. CNSA 2.0 establishes a timeline: software and firmware signing must transition to post-quantum by 2025, with full transition of all systems by 2030. NIST SP 800-131A specifies algorithm transition requirements. The Federal Financial Institutions Examination Council (FFIEC) has issued guidance on cryptographic risk management that explicitly references the quantum computing threat.

For banks, the regulatory pressure flows through multiple channels. Federal Reserve-supervised institutions must comply with SR letters on information security. OCC-supervised national banks must comply with the Comptroller's Handbook requirements on audit trail integrity. FDIC-supervised institutions must comply with examination procedures that reference NIST standards. All of these channels point in the same direction: classical cryptographic signatures on audit trails are a ticking liability, and the migration to post-quantum signatures is when, not if.

Banks that move early gain two advantages. First, records signed with post-quantum cryptography today are protected against the harvest-now-decrypt-later threat immediately. Every day of delay is another day of audit records that are vulnerable to future quantum forgery. Second, early movers establish examination precedent. When your examiner sees post-quantum signatures on your audit trails and asks about it, you demonstrate that your institution is ahead of the regulatory curve. That conversation goes differently than explaining why your 2026 audit records are still signed with RSA-2048 in a world where quantum computers exist.

What this means for AI in banking

The audit trail problem is about to get significantly worse because of AI. Banks are deploying AI agents for fraud detection, credit decisioning, AML screening, customer service, and compliance monitoring. Every AI decision that affects a customer — a declined transaction, a frozen account, a flagged wire — generates regulatory liability. Regulators will ask: what did the model produce? What data was it given? Was the output altered between the model and the action?

Classical audit trails cannot answer these questions with cryptographic certainty. They can show what was logged. They cannot prove that what was logged is what actually happened. Post-quantum attestation via H33-74 changes this. Every AI inference can be attested at the point of production — the model input, the model output, the model version, the timestamp — all bound to a 74-byte substrate that is independently verifiable by any regulator with the public key set. No trust required in the bank's logging infrastructure. No trust required in the AI vendor's claims about what their model produced. Mathematical proof, independently verifiable, quantum-resistant.

This is the direction banking is going. AI decisions that affect customers will require the same audit trail rigor that wire transfers and loan approvals currently require. The difference is that AI decisions happen at machine speed — thousands per second, not hundreds per day. The audit trail infrastructure needs to keep up. At 2,216,488 attestations per second, H33 can attest every AI decision a bank makes in real time, with three-family post-quantum security, at a persistent footprint of 74 bytes per decision.

The cost of waiting

Every day that passes without post-quantum audit trail protection is another day of records entering the harvest-now-decrypt-later vulnerability window. For a bank with a seven-year retention requirement, records created today need to remain cryptographically verifiable until 2033. Records created in 2027 need to survive until 2034. The quantum computing timeline is uncertain, but the most conservative estimates from the intelligence community suggest large-scale quantum computers capable of breaking RSA-2048 by the early 2030s. The less conservative estimates suggest sooner.

The cost of migration is an API call and 74 bytes of storage per record. The cost of not migrating is a compliance liability that grows by one day's worth of records every day you wait. For a large bank, that is millions of records per day entering the vulnerability window with no path to retroactive protection — you cannot go back and re-sign historical records with post-quantum signatures because the original signing keys and authorization context no longer exist in the required form.

The mathematics is clear. The standards are finalized. The regulatory direction is set. The implementation exists and runs at production scale today. The only question is whether your institution starts protecting its audit trails now, or explains to examiners later why it didn't.

H33 implements all three NIST post-quantum signature families in a single 74-byte attestation primitive that integrates with existing banking infrastructure through a single API call. The verification path is open and independently auditable. The throughput exceeds any banking workload by orders of magnitude. The persistent footprint is negligible. The regulatory alignment is complete.

Post-quantum audit trails are not a feature. They are infrastructure. And the banks that deploy them first will be the banks that can prove their compliance decisions were legitimate when the quantum era arrives and everyone else's proof has expired.