No. PCI DSS does not apply to ACH transactions. The standard is scoped to one thing: the primary account number printed on a payment card, along with related card data. ACH transfers move money using bank routing and account numbers, which are a different category of financial information with their own rulebook. So the short answer to whether PCI compliance applies to ACH is that it doesn’t — but that clean line gets messy fast if your ACH processing shares infrastructure with any system that touches card data, and ACH carries its own serious security obligations under separate frameworks.
Why ACH Sits Outside PCI DSS
PCI DSS applies to any entity that stores, processes, or transmits cardholder data or sensitive authentication data. Cardholder data means the primary account number, cardholder name, expiration date, and service code. Sensitive authentication data covers magnetic stripe contents, the CVV or CVC verification code, and PIN data. The PCI Security Standards Council puts the scoping test plainly: “PCI DSS does not apply if PANs are not stored, processed, or transmitted.”1PCI Security Standards Council. PCI Data Storage Dos and Donts
ACH transactions involve none of those data elements. A routing number is not a PAN. A bank account number is not a PAN. There’s no verification code, no magnetic stripe, no PIN block tied to the card networks. A business that runs only ACH payments does not need a PCI assessment, a Self-Assessment Questionnaire, or a Report on Compliance. That isn’t a workaround; it’s how the standard is built. PCI protects the card payment channel. ACH is governed elsewhere.
One thing worth being clear on: PCI DSS compliance is contractual, not statutory. Card brands require it through agreements with acquiring banks, which pass the requirement down to merchants. Fines for non-compliance generally run from $5,000 to $100,000 per month depending on volume and severity, imposed by the card brands on the acquiring bank and then forwarded to the merchant.
The Rules That Do Apply to ACH
Stepping out of PCI scope does not leave ACH unregulated. Any business originating or facilitating ACH payments operates under its own stack of requirements.
Nacha Operating Rules
Nacha governs the ACH network and administers the Operating Rules that bind every participant.2Nacha. About Us Article One, Section 1.6 requires non-consumer originators and third-party senders to maintain data security programs protecting bank account and routing information.3Nacha. Supplementing Data Security Requirements Phase 1 Organizations exceeding 2 million ACH entries per year must render stored account numbers unreadable. ACH data transmitted over unsecured networks must be protected with commercially reasonable encryption.4Nacha. Understanding the Value of Encryption in the ACH Network
New fraud-detection rules take effect in 2026. Phase One begins March 20, 2026, requiring originating depository financial institutions with 2023 origination volumes of $6 million or more to implement fraud-detection processes. By June 22, 2026, all participants must have risk-based policies and procedures designed to identify potentially fraudulent entries before they hit the network.5Nacha. Breaking Down Nachas New Risk Management Rules for ODFIs and RDFIs
The FTC Safeguards Rule
Issued under the Gramm-Leach-Bliley Act, the Safeguards Rule requires “financial institutions” under FTC jurisdiction to maintain a comprehensive information security program covering all customer data, including bank account numbers used for ACH.6eCFR. 16 CFR Part 314 – Standards for Safeguarding Customer Information The definition is broader than it reads: mortgage lenders, payday lenders, finance companies, account servicers, check cashers, wire transferors, collection agencies, tax preparation firms, and non-federally-insured credit unions are all covered. A standard retail merchant accepting ACH for occasional purchases probably sits outside the definition, but any business whose core activity is financial should assume it applies.
Covered businesses must implement access controls, encrypt customer information in storage and transit, deploy multi-factor authentication for anyone accessing customer records, and run annual penetration tests plus vulnerability scans at least every six months.7Federal Trade Commission. FTC Safeguards Rule: What Your Business Needs to Know Customer information must be disposed of within two years of last use unless there’s a legal or legitimate business reason to keep it longer.
Regulation E
The Electronic Fund Transfer Act, implemented through Regulation E, governs consumer liability for unauthorized ACH debits. When a consumer successfully disputes an unauthorized debit, the originating business tends to absorb the loss.8Consumer Financial Protection Bureau. 12 CFR 1005.6 – Liability of Consumer for Unauthorized Transfers That gives security practices a direct financial payoff: fewer compromises mean fewer disputes.
When ACH Gets Pulled Into PCI Scope Anyway
This is where the clean separation breaks. The cardholder data environment includes all systems, processes, people, and technology that store, process, or transmit cardholder data. If your ACH processing shares a network segment, a server, a database, or even a workstation with any system that touches card data, your ACH system can fall inside PCI audit scope.
This is scope creep, and it’s expensive. Once an ACH system is considered connected to or capable of impacting the cardholder data environment, an assessor has to evaluate it. The system must then meet every applicable PCI DSS requirement — encryption, logging, access controls, vulnerability scanning — even though the data it handles would otherwise be exempt. Full Reports on Compliance for larger enterprises can run into six figures.
Businesses that grow organically tend to pile payment functions onto shared infrastructure because it’s cheaper in the moment. A single misconfigured firewall rule or a shared credentials database can drag an entire ACH operation into PCI scope.
Keeping the Two Environments Separate
The most reliable defense is network segmentation: physically or logically isolating systems that handle card data from everything else. Done properly, segmentation confines the cardholder data environment to a defined boundary, and systems outside that boundary stay out of scope. The word “properly” is doing the work. Segmentation an assessor can poke holes in doesn’t reduce scope; it creates false confidence.
Two technologies shrink the footprint further. Tokenization replaces sensitive numbers with random strings that have no exploitable value. When card data never touches your systems because a tokenization provider handles it, those systems drop out of PCI scope. The same model works for ACH data; several payment platforms now tokenize bank account numbers at the point of entry so the actual account data never resides on merchant infrastructure.
Point-to-Point Encryption takes a different angle. PCI-validated P2PE solutions encrypt card data at the physical point of interaction and keep it encrypted until it reaches the solution provider’s decryption environment. Because clear-text card data never exists in the merchant’s environment, the number of PCI DSS requirements the merchant has to satisfy drops substantially.9PCI Security Standards Council. PCI Point-to-Point Encryption Security Requirements and Testing Procedures v3.1
For a business running both card and ACH payment channels, the practical move is to treat them as separate environments from day one. Separate networks, separate servers, separate access credentials. Retrofitting segmentation into tangled infrastructure costs far more than designing the separation up front.
Third-Party Processors Handling Both
Outsourcing processing does not outsource the compliance obligation. Under PCI DSS, merchants must keep an inventory of every third-party provider with access to cardholder data, monitor their compliance status, and review their PCI validation documentation at least annually.10PCI Security Standards Council. Third-Party Security Assurance Information Supplement
Due diligence before signing should cover PCI DSS compliance status, breach history, financial stability, any subcontracted service providers, and business continuity plans. Documentation and compliance evidence should be retained for a rolling three-year minimum. The contract itself should spell out breach notification procedures, including a commitment to cooperate with a PCI forensic investigator.
This matters especially when a single provider handles both card and ACH. If the provider’s ACH infrastructure isn’t properly segmented from its card infrastructure, their scope problem becomes your scope problem. Ask for documentation showing how the environments are separated. If a provider can’t produce it, treat that as a red flag.
What Non-Compliance Costs on Each Side
PCI and Nacha enforcement run on separate tracks, and both carry real weight. PCI DSS fines imposed by card brands through acquiring banks generally fall between $5,000 and $100,000 per month for ongoing non-compliance. A confirmed breach adds forensic investigation costs, mandatory customer notification, potential lawsuits, and, in severe cases, termination of the merchant’s ability to accept card payments.
Nacha classifies violations into three tiers. A Class 3 violation, the most severe, carries sanctions up to $500,000 per occurrence along with a directive for the originating bank to suspend the offending party.11Nacha. ACH Network Rules: Reversals and Enforcement Losing ACH access means no direct deposits, no automated bill payments, no recurring debits. For businesses that rely on bank-to-bank transfers, that kind of suspension can stop operations.
Businesses handling both payment types face both enforcement regimes at once. A security failure in a shared environment can trigger PCI penalties from card brands and Nacha sanctions from the ACH side simultaneously. Maintaining proper segmentation and following each framework’s requirements on its own terms is the most reliable way to keep one problem from becoming two.