← Back to Blog Industry

ACH Transfers and Post-Quantum Cryptography

12 min read

When you pay your electric bill from your bank's website, get your direct deposit on payday, or set up an automatic mortgage payment, you are using the Automated Clearing House network. ACH is the high-volume, low-cost payment rail that handles roughly 31 billion transactions worth around 80 trillion dollars annually in the US. It is operated by two clearing houses (the Federal Reserve's FedACH and The Clearing House's EPN) and governed by the rules of NACHA, the National Automated Clearing House Association.

ACH is older than the public internet. The first nationwide ACH operated in 1972. The cryptographic protections that wrap ACH files today are layered on top of an architecture that was originally designed to move plain-text fixed-width files through dial-up modem connections. Those protections work, but they all depend on classical public-key cryptography that a sufficiently powerful quantum computer can break.

This article explains how ACH cryptography actually works in 2026, what NACHA's Operating Rules require, and how Same Day ACH and WEB debit transactions interact with the post-quantum migration.

How ACH Actually Works

ACH is a batch system. An originator (employer, biller, retail merchant) submits a file of credit or debit transactions to its Originating Depository Financial Institution (ODFI). The ODFI batches transactions and sends them to an ACH operator (FedACH or EPN). The operator routes each transaction to the Receiving Depository Financial Institution (RDFI). Settlement happens between the ODFI and RDFI on the agreed settlement date through the Federal Reserve's National Settlement Service.

The format of an ACH file is the NACHA file format: fixed-width 94-character records called File Header (record type 1), Batch Header (5), Entry Detail (6), Addenda (7), Batch Control (8), and File Control (9). The file is a plain-text artifact. It contains routing numbers, account numbers, dollar amounts, transaction codes, and originator-supplied metadata.

Because the file is plain text, every layer that touches it must add cryptographic protection. The protections are:

Transport encryption. The file is moved between ODFI, ACH operator, and RDFI inside an encrypted tunnel. Today this is FTPS, SFTP, AS2, or a vendor-specific connection like FedLine.
File-level signing. The submitting institution signs the ACH file using S/MIME, OpenPGP, or a NACHA-defined signing format. The receiving operator verifies the signature.
Channel authentication. The ODFI and the ACH operator authenticate to each other using X.509 certificates.

All three layers depend on RSA, ECDSA, or static Diffie-Hellman as their public-key foundation. None of them survives Shor's algorithm. Read more in Why RSA-2048 Will Break.

NACHA Operating Rules and Cryptography

NACHA publishes the Operating Rules every year. The rules are binding on all ACH participants. The cryptographic requirements live in Article Two and Article Five.

The current rules require:

All ACH file transmissions over public networks must be encrypted using "commercially reasonable" encryption. Practical interpretation: TLS 1.2 minimum, AES-128 minimum, RSA-2048 minimum.
All ACH file transmissions to ACH operators must use mutual authentication.
WEB debits (Internet-initiated) and TEL debits (telephone-initiated) require additional authentication of the consumer authorization, typically via account verification methods.
For Same Day ACH, the cutoff windows mean that cryptographic operations must complete in seconds, not minutes.

The rules are deliberately algorithm-agnostic. They say "commercially reasonable" rather than naming specific algorithms. This gives NACHA the flexibility to update guidance as algorithms age. As of 2026 NACHA has signaled in advisory communications that PQC support will become a "commercially reasonable" expectation by the late 2020s.

WEB Debits: The Consumer-Facing Authentication

A WEB debit is an ACH debit authorized over the Internet. When you authorize an electric utility to debit your checking account on the utility's website, that is a WEB debit. NACHA Operating Rules require additional fraud-prevention measures for WEB debits because the originator is not face-to-face with the consumer.

The required measures include:

Account validation. The originator must validate that the account number provided is a valid account at the routing number's institution. This is typically done through a service like Early Warning (Plaid uses Early Warning data) or Nacha's account validation database.
Identity verification. The originator must take "commercially reasonable" steps to verify the consumer's identity. This often involves out-of-wallet questions, ID document upload, or login verification with the bank.
Encryption of the authorization. The consumer's authorization (clicking "I authorize") and the entered account information must be transmitted over an encrypted connection.

The encryption is TLS to the originator's website. TLS itself depends on classical cryptography until the migration to hybrid PQC TLS is complete. Read more in Hybrid Encryption.

Same Day ACH and Time Pressure

Same Day ACH was introduced in three phases over 2016 to 2018. It allows ODFIs to submit ACH files in defined windows (currently 10:30 am ET, 2:45 pm ET, and 4:45 pm ET) for same-day settlement. The throughput cap was raised to 1 million dollars per transaction in 2022.

The cryptographic implication is that ACH operators must perform the full envelope verification, signature check, and routing in seconds. There is no time for fallback retries on slow keys. This affects PQC migration planning because the new ML-DSA signatures are larger than RSA signatures. ML-DSA-44 signatures are 2,420 bytes versus RSA-2048's 256 bytes. ML-DSA-65 signatures are 3,309 bytes. The larger signatures fit comfortably in modern bandwidth, but every PQC implementation needs to be benchmarked against the Same Day ACH cutoffs. Read more in ML-KEM Explained.

The Quantum Threat to ACH Archives

ACH files are retained by ODFIs and RDFIs for at least seven years under NACHA rules and longer under various state-level regulations. The retained files contain account numbers, routing numbers, amounts, and originator names. Encrypted at rest, encrypted in transit, but the encryption keys are themselves wrapped with classical RSA or ECDH.

A harvest-now-decrypt-later adversary collecting ACH transmission traffic in 2026 and decrypting it after Q-Day in (say) 2035 obtains a multi-year archive of every direct deposit, every bill payment, every payroll run for whatever institutions the adversary captured. That is exactly the data that informs identity theft, account takeover, and targeted phishing campaigns.

This is the threat motivating the PQC migration. Read more in Harvest Now, Decrypt Later.

What Banks and Originators Need to Do

A bank participating in ACH has multiple cryptographic systems to migrate:

The connection to FedACH uses FedLine's certificate-based authentication. FedLine itself is migrating to PQC under the Federal Reserve's broader plan. Read more on Fedwire and PQC here.
The connection to EPN uses TLS with X.509 certificates issued by The Clearing House.
The internal payment hub. The system that receives consumer payments, builds ACH files, and submits them. Vendors include ACI Worldwide, Finastra, Volante, and many in-house systems.
The signing system for ACH files. Often a separate HSM that holds the bank's signing key.
Customer-facing online banking. TLS termination, certificate management, key rotation.

For an originator (a corporate that initiates payroll or bill payments), the migration scope is smaller but still includes:

Their connection to the ODFI (typically SFTP with public-key authentication).
Any internal systems that store account credentials.
Web-facing TLS for consumer authorization.

NACHA has indicated that revised guidance on PQC will be issued in stages over 2026 to 2030. The expectation is hybrid migration starting around 2027 with classical fallback retired by 2032 to 2035.

NIST Algorithms in Scope

The NIST standards that apply to ACH PQC migration are FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). For ACH file signing, ML-DSA-65 in hybrid with RSA-3072 or ECDSA P-256 is the most likely target. For TLS connections, ML-KEM-768 in hybrid with X25519 is standard.

ML-DSA-65's 3,309-byte signature is larger than RSA-2048's 256 bytes, but ACH files are typically megabytes in size, so the relative overhead is small. ML-KEM-768's 1,184-byte ciphertext fits easily in any TLS extension. Read more in our NIST FIPS guide.

Service Bureau Considerations

A large portion of US small banks and credit unions do not connect directly to FedACH or EPN. Instead they connect through a service bureau (Jack Henry, Fiserv, FIS, Aliaswire, and dozens of others). The service bureau aggregates ACH traffic from many small institutions and submits to the ACH operator on their behalf.

For PQC migration, the service bureau model adds a layer of dependency. The service bureau's PQC roadmap dictates when its client banks can flip on hybrid PQC. Most major service bureaus indicated in 2025 industry communications that their PQC enablement would happen in lockstep with the ACH operators' enablement, not before. Smaller service bureaus may lag.

Banks that connect through a service bureau should ask their service bureau provider for a written PQC migration timeline. The question is not "will you migrate" (the answer is yes, mandatory eventually) but "when" and "how do you handle hybrid mode during transition."

Vendor Ecosystem and TR-31 Key Blocks

ACH file signing keys live inside HSMs. The keys are typically packaged in TR-31 key blocks per ANSI X9.143 (formerly X9 TR-31). TR-31 is a binary format for transferring keys between HSMs that includes algorithm identifiers, usage attributes, and integrity protection.

The ANSI X9F1 working group is updating TR-31 / X9.143 to include ML-KEM and ML-DSA key types. Once the updated standard is published, HSM vendors will roll out firmware that produces and consumes TR-31 blocks for the new algorithms. Banks need to test that their key ceremony procedures (key loading, key rotation, key deletion) work end-to-end under the updated TR-31 spec.

How QNSQY Fits

QNSQY does not connect to FedACH or EPN and does not produce ACH files. But it does encrypt files using NIST-standardized post-quantum cryptography, which makes it useful for the supporting data ecosystem around ACH:

Archival of original ACH files for the seven-year retention window.
Encrypted transfer of return files (NOC, R-codes) between corporate originators and their ODFI.
Backup of payment hub configuration, signing keys (in encrypted exports), and audit logs.
Encrypted transfer of test files between developers and the bank's certification team.

QNSQY uses ML-KEM-512/768/1024 in hybrid with X25519 for key encapsulation, ML-DSA-44/65/87 in hybrid with Ed25519 for signatures, AES-256-GCM for data encryption, and Argon2id for password-based key derivation. The .qs polyglot file format is engineered to remain readable for decades, which matches the seven-to-twenty year retention requirements that ACH data falls under. Read more in Encrypt Before Cloud Upload.

FAQ

Are ACH files encrypted today? Yes. ACH files are encrypted in transit using TLS or SFTP and at rest using AES under bank-managed key hierarchies. The classical public-key algorithms protecting those keys are vulnerable to a future quantum computer.

Has NACHA mandated PQC? Not yet. NACHA's current rules require "commercially reasonable" encryption, which is deliberately algorithm-agnostic. NACHA has signaled forthcoming guidance on PQC.

Will Same Day ACH still work after PQC migration? Yes. The new ML-DSA signatures are larger than RSA but verification is fast enough to fit within Same Day ACH's cutoff windows. Implementation benchmarking is required.

What about WEB debits and online banking? Online banking TLS will migrate to hybrid PQC TLS. The major browser vendors (Chrome, Firefox, Edge, Safari) shipped initial hybrid PQC TLS support in 2024 and 2025. Banks need to update their TLS termination infrastructure to match.

Is QNSQY a NACHA-certified product? QNSQY is a general-purpose post-quantum cryptography tool. It is not a NACHA-certified ACH origination product. It is appropriate for archives, backups, and out-of-band data transfer that supports ACH compliance.

Sources

NACHA, "Operating Rules and Guidelines" : https://www.nacha.org/rules
NACHA, "Same Day ACH" : https://www.nacha.org/products/same-day-ach
Federal Reserve, "FedACH Services" : https://www.frbservices.org/financial-services/ach
NIST FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA), August 2024 : https://csrc.nist.gov
NIST IR 8547, "Transition to Post-Quantum Cryptography Standards" : https://csrc.nist.gov

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY