PCI-DSS 4.0.1 came into full enforcement on January 1, 2025 replacing both PCI-DSS 3.2.1 and the original 4.0, and it has materially changed what acquiring banks, PSPs, and payment facilitators have to demonstrate about the merchants in their portfolios. The cardholder-data protection standard has always made the acquirer responsible for the compliance of every merchant in its book of business, but 4.0.1 expanded that responsibility into territory most acquirer compliance programs are not currently set up to operate in.
The two biggest operational shifts are easy to name. First, payment-page integrity requirements 6.4.3 and 11.6.1; now requires continuous detection of injected scripts and tampered checkouts. Most merchants cannot do this themselves, and the cost of missing it falls on the acquirer. Second, sub-Payment Facilitator (sub-PF) oversight has been formalized into explicit acquirer obligations: when a PF operates aggregated sub-merchants in the portfolio, the acquirer is responsible for ensuring the PF actually validates those sub-merchants.
This guide walks through what acquirers actually have to do under PCI-DSS 4.0.1 on the merchant side from SAQ classification and document lifecycle, to sub-PF oversight, to the new e-skimming detection mandate and where the gaps usually open up at portfolio scale.
What is PCI-DSS 4.0.1?
PCI-DSS 4.0.1 is the active version of the Payment Card Industry Data Security Standard, published in June 2024 by the PCI Security Standards Council. It supersedes the original 4.0 release (March 2022) and fully replaces the long-running 3.2.1 standard. 4.0.1 is a clarifications-and-errata update. It does not introduce new requirements relative to 4.0 but it became the only valid version for new assessments from January 1, 2025 onward.
The structural changes versus 3.2.1 are the ones that matter operationally:
-
Customized approach; entities can implement controls with compensating mechanisms as long as they document a targeted risk analysis and demonstrate equivalent protection.
-
Targeted risk analyses; entities must perform documented risk assessments for many controls rather than relying purely on prescriptive frequency.
-
Stronger authentication; multi-factor authentication is now required for all access into the cardholder data environment, not just remote administrative access.
-
Payment-page integrity; requirements 6.4.3 (authorization, integrity check, and inventory of every script on payment pages) and 11.6.1 (mechanisms that detect tampering with payment pages and alert in near real time). These are the requirements that address e-skimming and Magecart-style attacks.
-
Authenticated scanning; internal vulnerability scans must be authenticated where possible.
For acquirers, the most consequential changes are payment-page integrity (6.4.3 / 11.6.1), the formalization of sub-PF oversight expectations, and the strengthened expectations on document lifecycle and evidence retention. The rest of this guide is built around those three operational shifts.
The Acquirer's Role Under PCI-DSS 4.0.1
PCI-DSS does not make the acquirer compliant on behalf of the merchant. It makes the acquirer responsible for ensuring the merchant is compliant. The distinction matters operationally and legally.
The card networks (Visa, Mastercard, American Express, Discover, JCB) each have their own compliance enforcement programs built on top of PCI-DSS. Each one holds the acquiring bank accountable when merchants in its portfolio fail to validate their PCI compliance status correctly. The fines are direct and uncapped: Visa's Global Merchant Audit Program (GMAP) penalties run to hundreds of thousands of dollars per non-compliant merchant identified during an audit cycle; Mastercard's Site Data Protection (SDP) program operates similarly. Repeated failures put the acquiring license itself at risk.
Acquirer obligations under PCI-DSS 4.0.1 break down into four operational responsibilities:
-
Categorize every merchant correctly; assign each one to the right merchant level (1–4) based on transaction volume and channel type.
-
Collect the right validation documents; SAQ, AoC, ASV scan reports — appropriate to that level and merchant type, on the right cadence.
-
Track validity and re-validation; most documents expire annually; ASV scans expire quarterly.
-
Report to the card networks; typically quarterly attestations of which merchants are compliant, which are in remediation, and which have failed validation.
The merchant does the technical work of compliance. The acquirer owns the program that proves it.
Merchant Level Segmentation and SAQ Classification
Card brands define merchant levels by annual transaction volume. The thresholds are not standardised across brands but follow a common shape:
-
Level 1 — 6M+ transactions per year, or any merchant with a confirmed breach. Annual on-site assessment by a Qualified Security Assessor (QSA) + quarterly ASV scans.
-
Level 2 — 1M–6M transactions per year. Annual SAQ (or QSA assessment) + quarterly ASV scans.
-
Level 3 — 20K–1M e-commerce transactions per year. Annual SAQ + quarterly ASV scans.
-
Level 4 — Fewer than 20K e-commerce transactions or fewer than 1M card-present transactions per year. Annual SAQ at acquirer discretion.
For Level 2 through Level 4, the acquirer's job is to make sure each merchant completes the right SAQ. Picking the wrong SAQ type is the single most common compliance failure across acquirer portfolios — and it is essentially impossible for most merchants to get right without guidance.
PCI-DSS 4.0.1 maintains the same nine SAQ types as 4.0:
-
SAQ A — Card-not-present merchants where all cardholder data functions are fully outsourced. Limited applicability.
-
SAQ A-EP — E-commerce merchants who partially outsource payment but control or influence the page that loads the payment iframe. This is the SAQ most affected by 6.4.3 and 11.6.1.
-
SAQ B — Merchants using imprint or standalone dial-out terminals (no electronic storage).
-
SAQ B-IP — Standalone IP-connected payment terminals.
-
SAQ C — Merchants with payment application systems connected to the internet (no e-commerce).
-
SAQ C-VT — Merchants using web-based virtual terminals only.
-
SAQ D-MER — All other merchants (the comprehensive form).
-
SAQ D-SP — Service providers eligible for SAQ.
-
SAQ P2PE — Merchants using validated point-to-point encryption solutions only.
A merchant that runs an e-commerce checkout where any JavaScript on the merchant's own domain interacts with the iframe or payment form belongs in SAQ A-EP, not SAQ A. Misclassifying an A-EP merchant as an A — which happens constantly — means the merchant attests to a set of controls that does not actually cover the risk they have, and the acquirer is accepting an attestation that does not represent the merchant's real environment. When that misclassification surfaces during a breach investigation or audit, the acquirer is the one explaining the gap to the scheme.
Document lifecycle: SAQ, AoC, and ASV scans
The PCI-DSS validation document set is not complex — but the lifecycle is, especially at portfolio scale.
The three documents that matter:
-
SAQ (Self-Assessment Questionnaire) — the merchant attests to specific PCI-DSS controls relevant to their environment. Annual renewal required.
-
AoC (Attestation of Compliance) — the signed legal attestation that accompanies the SAQ. It is the document the acquirer files with the card brand.
-
ASV (Approved Scanning Vendor) reports — quarterly external vulnerability scans performed by a vendor approved by the PCI SSC. Required for Levels 1, 2, and 3 (and for any merchant performing card-not-present transactions over a public network).
The operational challenge for acquirers is volume and channel chaos. SAQs come back from merchants through whatever channel happened to be convenient — sales rep email, customer portal upload, branch fax, occasionally a paper form sent to head office. AoCs and ASV reports follow the same haphazard path. Without centralization, the acquirer's actual portfolio compliance posture diverges from the reported compliance posture, and the audit surfaces the divergence at the worst possible time.
A working program handles four things simultaneously
- Smart SAQ classification — guide merchants to the correct SAQ before they fill it in, not after they file the wrong one.
- Centralized document intake — every document, regardless of submission channel, lands in a single dashboard tagged to a merchant record.
- Validity tracking with renewal alerts — every document carries an expiry, and the merchant is reminded well before the expiry, not on the day of.
- Audit-ready export — the full record per merchant, per validation cycle, exportable on demand.
These are the four things Onlayer's Merchant PCI-DSS Management is built to do at portfolio scale. We come back to it in the closing section.
Sub-PF and Sub-merchant Oversight
Payment Facilitators (PFs; entities that aggregate sub-merchants under their own MID)) are explicitly addressed under PCI-DSS 4.0.1 and under the card-brand programs that sit on top of it (Visa Payment Facilitator Program, Mastercard Payment Facilitator Compliance Program).
The acquirer's responsibilities around PF and sub-PF management are:
-
Validate the PF's own PCI compliance — the PF itself must be PCI-DSS Level 1 compliant, with a full on-site assessment by a QSA.
-
Validate the PF's underwriting of sub-merchants — the PF must be performing proper KYM, PCI status validation, and ongoing compliance monitoring of its sub-merchants. The acquirer must verify that this process exists and is functioning.
-
Apply transaction-volume thresholds for sub-merchants — Visa's standard threshold for elevating a sub-merchant out of aggregated reporting is around $1M annual processing; Mastercard's varies but operates on the same principle. Above the threshold, the sub-merchant is no longer aggregated and must be onboarded as a direct merchant under PCI-DSS.
-
Maintain visibility into sub-merchant compliance status — including SAQ status, scan compliance, and any open vulnerabilities.
The structural problem is that the acquirer is one step removed from the sub-merchant. The PF is closer, the PF has the contractual relationship, the PF holds the data. When the scheme asks the acquirer for evidence about a specific sub-merchant's compliance posture, the acquirer typically has to chase the PF, who chases the sub-merchant, who eventually sends back a document set that hasn't been validated by anyone in between.
What audit-ready sub-PF oversight looks like:
-
A documented PF compliance file: the PF's own AoC, evidence of sub-merchant onboarding controls, sample sub-merchant validation records.
-
A sub-merchant register accessible to the acquirer (read-only is fine), with each sub-merchant's PCI status, SAQ type, last scan date, and current threshold position.
-
Automated alerts when a sub-merchant crosses the elevation threshold and needs to be re-onboarded as a direct merchant.
-
A defined re-validation cadence — typically annual at the PF level, with quarterly review of high-risk sub-merchants.
This is the operational layer most acquirer programs underbuilt. The PF compliance check happens at onboarding, the sub-merchant register exists somewhere, and a quarterly threshold review is on someone's calendar but the three are not connected, and when a scheme audit lands, the acquirer reconstructs the evidence from spreadsheets and inboxes.
E-skimming, Mage-cart, and requirements 6.4.3 + 11.6.1
The single most operationally consequential change in PCI-DSS 4.0 / 4.0.1 is the payment-page integrity requirement set. These are the controls that address e-skimming also called Mage-cart attacks, web skimming, or digital skimming where attackers inject malicious JavaScript into a merchant's checkout page to steal cardholder data as it is entered.
Requirement 6.4.3 mandates that every script loaded on a payment page is:
-
Authorised (the merchant explicitly approved its presence)
-
Integrity-validated (the merchant has a mechanism to verify the script has not been altered)
-
Inventoried with a documented business justification
Requirement 11.6.1 mandates a change-detection mechanism that:
-
Monitors HTTP headers and payment-page content for unauthorised modification
-
Generates alerts on detected changes
-
Performs evaluations weekly at minimum (or on a frequency justified by targeted risk analysis)
Together, these requirements describe a continuous client-side monitoring capability that simply did not exist in the previous version of the standard. Both became fully enforceable for assessments starting March 31, 2025.
The operational problem is that most merchants especially SAQ A-EP merchants, who are most at risk from e-skimming do not have the technical capability to implement these requirements themselves. The merchant uses a content management system, loads dozens of third-party scripts (analytics, marketing tags, A/B testing, customer support widgets, CDN-hosted libraries), and has no visibility into when any of those scripts are altered by their respective vendors, much less when something malicious is injected mid-supply-chain.
The acquirer's exposure is direct. If a merchant in the portfolio is compromised by a Magecart attack and exfiltrates cardholder data while their SAQ A-EP attestation claims they have 6.4.3 and 11.6.1 controls in place, the portfolio just absorbed a non-compliance finding plus a personal-data breach notification under the relevant national framework — and the scheme will treat the acquirer's oversight as part of the failure.
This is the gap Onlayer's Merchant Malware & Eskimming Module is designed to close. We come back to it in the closing section.
The National data-protection overlap
A skimming incident is rarely a single-regulator problem. Cardholder data theft on a merchant site under your acquiring portfolio is simultaneously:
-
A PCI-DSS non-compliance event (scheme-level)
-
A national personal-data breach (regulator-level)
-
A potential consumer-protection event (national consumer authority)
For acquirers operating in the GCC, UK, Türkiye, and EU, the parallel regulatory frameworks that apply on top of PCI-DSS include:
-
KVKK (Türkiye, Law No. 6698) — 72-hour breach notification, mandatory data protection officer for high-risk processors, financial penalties measured against annual revenue.
-
UAE PDPL (Federal Decree-Law No. 45 of 2021) — breach notification to the UAE Data Office, with timing measured in hours for material risk to data subjects.
-
KSA PDPL (Royal Decree M/19 of 2023) — breach notification to SDAIA (Saudi Data and AI Authority) with strict timing.
-
GDPR (EU 2016/679) / UK GDPR — 72-hour notification window to the supervisory authority, plus notification to affected data subjects where high risk to rights and freedoms is established.
-
CBUAE Notice 3057 — UAE Central Bank's fraud-prevention mandate, with specific merchant-monitoring expectations.
-
SAMA Cybersecurity Framework — KSA Central Bank requirements for licensed financial institutions.
Cardholder and personal data theft directly affects the security of every citizen whose information was on the merchant's checkout page. National regulators treat that as a sovereign issue, not a card-scheme matter and the notification clocks they enforce move faster than scheme audits do.
For an acquirer, this means the same incident generates parallel reporting obligations into multiple regulatory frameworks, each on its own timeline. The acquirer that monitors continuously catches the incident in time to notify on the regulator's timeline. The acquirer that monitors annually catches the incident from the regulator.
Audit-readiness under 4.0.1
Audit-readiness under 4.0.1 has shifted from "produce the documents when asked" to "produce continuous evidence on demand." For acquirers, that means a programme that:
-
Maintains a single source of truth for every merchant's compliance status, refreshed continuously.
-
Generates exportable evidence for any merchant at any point in their compliance cycle — SAQ, AoC, ASV history, all version-controlled.
-
Captures change-detection logs for payment-page integrity continuously, with timestamps and tamper-resistant retention.
-
Produces compliance reports formatted for the scheme (Visa GMAP, Mastercard SDP) and for relevant national regulators (CBUAE, SAMA, KVKK supervisory authority, ICO, UAE Data Office, SDAIA).
-
Tracks every sub-PF and every sub-merchant flagged through PF oversight, with elevation thresholds monitored automatically.
The cost of not operating this way is no longer abstract. Acquirers who absorb PCI-DSS non-compliance findings, or who fail to demonstrate adequate oversight of merchants in their book, are subject to direct scheme fines, regulatory enforcement actions, and license-level consequences that compound over time. The cost of a well-run program is materially smaller than the cost of a single major finding.
How Onlayer Automates PCI-DSS 4.0.1 Compliance End-to-End
Two Onlayer modules sit directly inside the acquirer's PCI-DSS 4.0.1 obligation. Together they cover both halves of the standard — the document lifecycle that proves controls exist, and the continuous monitoring that proves the controls are actually working.
Onlayer's Merchant PCI-DSS Management automates the document lifecycle that sits underneath the entire compliance programme. The Intelligent PCI Wizard guides merchants to the exact SAQ type (A, A-EP, B, B-IP, C, C-VT, D, P2PE) automatically using smart Q&A logic — eliminating the most common cause of attestation failure. Centralised intake consolidates SAQs, AoCs, and ASV reports into a single dashboard regardless of submission channel, driving up to an 85% increase in completed compliance submissions portfolio-wide. Validity tracking monitors document expiry continuously and triggers automated renewal reminders before lapses become audit findings. Audit-ready evidence generates export-ready compliance reports for scheme audits (Visa GMAP, Mastercard SDP) and national regulators on demand. Sub-PF oversight workflows support the PF compliance file and sub-merchant register that PCI-DSS 4.0.1 expects acquirers to maintain.
Onlayer's Merchant Malware & Eskimming Module closes the requirement 6.4.3 / 11.6.1 gap that most merchants cannot close on their own. Continuous payment-page scanning monitors every script, iframe, and tag loaded on merchant checkout pages — including dynamically injected, lazy-loaded, and third-party-hosted code. Behavioural detection matches against known eskimming families (Magecart variants, formjackers, mobile injectors) and flags suspicious activity through heuristics — keystroke logging, cross-domain form posting, obfuscated payloads, unauthorised endpoint exfiltration. Detection output maps directly to PCI-DSS 4.0.1 requirements 6.4.3 (authorised payment-page scripts) and 11.6.1 (change and tamper detection). Tamper-resistant evidence logs, timestamped script snapshots, and forensic chains satisfy QSA assessment, scheme review, AND national data-protection breach-notification timelines under a single output — with jurisdiction-aware audit reports for PCI-DSS, CBUAE Notice 3057, SAMA, KVKK, UAE PDPL, KSA PDPL, and GDPR / UK GDPR.
Deployed alongside Onlayer's Merchant Monitoring Service, BRAM/VIRP Checks, and Merchant Onboarding Service, the two PCI-DSS modules become part of a connected compliance fabric across the merchant lifecycle — from onboarding KYM, through continuous scheme-aligned monitoring, to payment-page integrity, to audit response. The two modules can also be deployed independently for acquirers who want to roll the PCI-DSS programme out in stages.
For acquirers running a portfolio of merchants and sub-PFs under PCI-DSS 4.0.1 today, the question is no longer whether to centralise the programme — schemes and regulators have made clear that periodic ad-hoc compliance is not sufficient — but how to do it at portfolio scale without exhausting the compliance team or accepting attestations that don't match operational reality.
Book a demo to see how Onlayer's PCI-DSS Management and Merchant Malware & Eskimming Module support both halves of the PCI-DSS 4.0.1 obligation across an active acquiring portfolio.
