Visa PCI DSS Rules: Who the Fine Actually Lands On

Visa does not fine merchants for failing PCI DSS. It cannot. Every non-compliance assessment in the Visa rules is imposed on a Member, which means your acquirer, and the rulebook goes one step further than that. Your acquirer is not allowed to tell you Visa fined you.

That rule is Section 1.11.2.5 of the Visa Core Rules and most merchants have never seen it. Here is what the 18 April 2026 edition actually says about card data security, where the money lands, and the one published dollar figure in the whole chain.

Who writes the standard and who enforces it#

These are two different organizations and the split explains almost everything else. Visa's own merchant guidance states that the PCI Security Standards Council "owns, maintains and manages the PCI DSS and all its supporting documents; however, Visa manages all data security compliance enforcement and validation initiatives."

So the Council writes the standard. Visa decides what happens when you miss it. Appendix A of the rulebook lists the PCI DSS as a Visa Supplemental Requirement, enforceable in all regions, alongside the Account Information Security (AIS) Program Guide. That is how a standard written by someone else becomes a term of your merchant agreement.

The rule that reaches you is Section 1.9.4.1 (ID# 0002228). It binds the Member, not you. It requires your acquirer to ensure that all of its agents and merchants with access to account or transaction information comply with PCI DSS, to write that responsibility and the liability for failing it into your contract, and to allow inspections by the Member or by Visa. Visa's merchant page cites the same rule ID, so this reading is not an interpretation.

What the rules forbid you from storing#

Separately from the standard itself, the Visa rules name six specific things that must never be stored after authorization. The list is worth reading closely, because three of the six are token era items that older PCI explainers predate.

If you built a tokenized or 3-D Secure flow and you log the verification values it returns, you are storing prohibited data. That is a quiet way to fail a requirement nobody mentioned to you. Our guide to PCI DSS compliance covers the standard itself in more detail.

The reporting cadence nobody tells merchants about#

Section 12.5.1.2 (ID# 0001753) puts your compliance status on a clock your acquirer has to keep. The Member must report and verify your PCI DSS status to Visa at least every six months. For level 3 merchants the rule is sharper still. A level 3 merchant must either use a PCI DSS compliant service provider exclusively, or hand its acquirer validation documentation of its own compliance.

Service providers run on a different clock. Visa's merchant page says issuers and acquirers must ensure every service provider demonstrates compliance at least every twelve months. Six months for merchants, twelve for providers. If your acquirer asks for a fresh attestation twice a year and it feels arbitrary, it is not. It is that rule.

Merchant level comes from volume, and the definition is narrower than most people assume. Visa sets it from the corporate entity's total Visa transaction volume over twelve months, counting credit, debit and prepaid, in one country or with one acquirer. Volume from independently owned locations such as a franchisee may be excluded if the corporate entity does not process it.

The only published figure is USD 100,000 per incident#

The AIS program assessment amounts are not in the public rulebook. Section 12.5.1.1 (ID# 0008193) simply points at the AIS Program Guide, which Visa does not publish openly. So anyone quoting you a specific PCI fine schedule is not reading it from the rules.

One figure is published. Section 12.5.1.3 (ID# 0003524) sets a non-compliance assessment of up to USD 100,000 per incident on a Member that fails to notify Visa immediately of a suspected or confirmed loss or theft of Visa transaction information, or fails to respond to it adequately or in time.

Read what that penalizes. It is not the breach. It is the silence afterwards. The clock on your acquirer starts at suspicion, not at confirmation, which is why their incident process will feel disproportionate to what you have found so far. What the recovery side of a breach looks like is covered in our piece on account data compromise.

Visa's guidance adds one relief worth knowing. Assessments may be waived where a forensic investigation finds no evidence of PCI DSS non-compliance before and at the time of the breach. Compliance at the moment it mattered is the thing being tested.

Why your statement cannot say Visa fine#

Section 1.11.2.5 (ID# 0001054) is short and unusually direct:

A non-compliance assessment is imposed by Visa on a Member. A Member is responsible for paying all non-compliance assessments, regardless of whether it absorbs them, passes them on, or increases them in billing its customer (for example: Cardholder or Merchant). A Member must not represent to its customer that Visa imposes any non-compliance assessment on its customer.

Both halves matter. Your acquirer may pass the cost to you, and may mark it up. What it may not do is present the charge as something Visa levied on you. Visa restates the prohibition on its own merchant page.

So a line item reading "Visa PCI non-compliance fine" is describing a charge your acquirer owes and has chosen to recover from you. Whether it can is a question about your merchant agreement, not about the Visa rules. Ask which assessment was levied, on what date, and which contract clause allows the pass through. Reading the rest of those charges is covered in how to read a merchant processing statement.

The exemption worth checking#

Visa's Technology Innovation Program can remove the requirement to validate PCI DSS compliance altogether. The threshold is that at least 75 percent of your yearly transactions originate through EMV chip enabled terminals, a validated point to point encryption solution, or integrated industry standard tokenization meeting the EMVCo Tokenization Specification.

That is a real exemption from the validation work, not from the security requirements. If you are a card present merchant near that 75 percent line, it is worth measuring before your next attestation cycle.