PCI DSS 4.0 requires organizations that store, process, or transmit payment card data to implement 12 principal, objective-based requirements and prove continuous, evidence-backed controls across their cardholder data environment. That single sentence carries a lot of operational weight, and you need to unpack it before you touch a single control.

Here’s what it means in practice:

  • Define your CDE and scope first. You cannot secure what you haven’t mapped, and every assessor will start there.
  • Choose your validation path. Merchants and service providers pick between a Self-Assessment Questionnaire (SAQ) and a full Report on Compliance (ROC), depending on transaction volume and risk profile.
  • Build continuous monitoring into daily operations. PCI DSS v4.0 penalizes organizations that treat compliance as a once-a-year fire drill rather than an operating discipline.

The PCI Security Standards Council (PCI SSC) publishes and maintains the standard, and validation typically involves either a Qualified Security Assessor (QSA) for larger environments or an Approved Scanning Vendor (ASV) for external network scans. If you’re a security officer or compliance manager trying to translate this into a work plan, the rest of this guide walks through exactly what to build, in what order, and what evidence to keep on hand.

Key Takeaways

PCI DSS 4.0 requires continuous, evidence-backed proof of 12 principal controls, and scope confirmation determines whether every other control is protecting the right boundary.

Point Details
Scope comes first Map data flows and system components before investing in any other control.
Continuous compliance is the standard Build ongoing evidence collection, not annual snapshots, into daily operations.
Match validation path to volume Use SAQ types for lower-volume merchants and ROC with a QSA for Level 1 organizations.
Reserve the Customized Approach Use it only when a unique architecture or existing control genuinely justifies the extra documentation.
Davincipay reduces scope directly Tokenization and gateway offload from Davincipay can shift merchants from SAQ D toward SAQ A.

Table of Contents

What Are the Key Changes in PCI DSS 4.0?

PCI DSS is a baseline of technical and operational controls built to protect cardholder data, and it applies to any entity that stores, processes, or transmits cardholder data or sensitive authentication data. The PCI SSC, a global body governed by the major card brands, owns the standard and updates it periodically to keep pace with how payment fraud actually evolves.

Version 4.0 is the biggest rewrite the standard has seen in years, and the shift isn’t cosmetic. Earlier versions told you exactly how to meet a control. Version 4.0 states the security objective and lets you choose how to get there, provided you can prove it works. That change alone reshapes how compliance teams document, test, and defend their environments.

A few changes stand out above the rest:

  • Continuous compliance replaces the annual snapshot. Controls need ongoing evidence, not just a clean bill of health once a year.
  • The Customized Approach lets you meet an objective with alternative controls, as long as you document and validate equivalence.
  • Scope and CDE language got more explicit, closing loopholes organizations used to argue systems out of scope.
  • Multi-factor authentication requirements expanded to cover all access into the cardholder data environment, not just remote access.
  • Targeted Risk Analysis (TRA) became a formal requirement for justifying flexible controls and custom testing frequencies.

PCI SSC groups the new and revised controls under three broad themes: Protection of Account Data, Response to Threats, and Flexibility, reflecting a standard built for continuous security rather than point-in-time compliance. Many of these new controls carry a future effective date of March 31, 2025, which has now passed, meaning most organizations should already have them operational.

Version 4.0.1 followed as a limited revision. It corrects errors and clarifies language from v4.0, and it introduces no new requirements and no new effective dates. If your team was already working from v4.0, you don’t need to restart. You need to re-read the clarified language, particularly around multi-factor authentication exceptions and payment page script management, since those areas caused the most assessor questions after the initial release.

Pro Tip: Keep a change log that maps every control you touch to the specific v4.0.1 clarification that prompted the change. Assessors ask “why did you change this” far more often than “did you change this,” and a documented rationale saves you from re-litigating decisions during the assessment.

How Do You Define PCI DSS Scope and Reduce It?

Scope determination is the single most consequential step in any PCI DSS program, and it’s also where most organizations get it wrong. Your cardholder data environment (CDE) includes every system component that stores, processes, or transmits account data, plus any component with unrestricted connectivity into that environment. Miss a connected system, and your entire scope determination is invalid, regardless of how strong your other controls are.

Hands managing network cables in data center

Producing a defensible annual scope confirmation takes three concrete steps. First, build a current data-flow diagram showing every location and path that account data travels, from the point of capture through settlement. Second, inventory every system component touching that flow, including third-party services, backup systems, and administrative jump boxes. Third, explicitly identify any component with unrestricted network access to the CDE, because PCI DSS treats that connectivity as equivalent to being inside the CDE itself. Requirement 12.5.2 requires you to keep revision history for this scope confirmation, not just a single snapshot, so version your diagrams and inventories the same way you’d version code.

Segmentation is how you shrink that scope down to something manageable:

  • Network segmentation with firewalls or VLANs isolates the CDE from the rest of your corporate network, so a compromised laptop in marketing can’t reach payment systems.
  • Tokenization replaces the primary account number (PAN) with a surrogate value, often removing entire systems from scope if they never touch the real card number.
  • Point-to-Point Encryption (P2PE) encrypts card data at the point of capture and keeps it encrypted until it reaches the processor, which can pull POS terminals largely out of scope.
  • Gateway offload, where a hosted payment page or iframe handles card entry, keeps raw PAN off your servers entirely.

Each of these has trade-offs. Tokenization reduces scope but shifts trust to your token vendor’s own security posture. P2PE reduces scope dramatically but locks you into validated hardware and a specific decryption partner. Gateway offload is often the fastest scope reduction for e-commerce merchants, but it only works if the checkout flow never touches your own servers, even during error handling or abandoned-cart recovery.

The most common scope-mapping mistake is assuming a system is out of scope because it “shouldn’t” have access to the CDE, rather than proving it can’t. Assessors test connectivity, not intentions. A second common failure is forgetting shared services, like a centralized logging server or an Active Directory domain controller, that touch both in-scope and out-of-scope systems and therefore pull the whole domain into scope by association.

Pro Tip: Run an internal network scan from a deliberately “out of scope” workstation aimed at your CDE before your assessor does. If you can reach anything you didn’t expect to reach, you’ve found your scoping gap for free.

Segmentation decisions need their own documentation trail: network diagrams showing the segmentation boundary, firewall rule sets proving the boundary is enforced, and a rationale for why each control point is sufficient. One of the more overlooked figures in PCI DSS programs is how much assessment cost and complexity concentrate in scope disputes rather than control gaps. Organizations that map scope precisely and document segmentation upfront routinely report shorter assessment cycles than those that let the QSA discover scope boundaries during testing. A firm that specializes in IT and compliance architecture for payment environments can be a useful second set of eyes on system inventory before your formal assessment begins.

What Are the 12 PCI DSS Requirements?

The 12 principal requirements group into six control objectives, and the Requirements and Testing Procedures document is the authoritative source assessors work from during testing. Understanding PCI DSS 4.0 at this level means knowing not just what each requirement demands, but what evidence proves you’ve met it.

Requirement 1: Install and maintain network security controls. This covers firewalls, network segmentation, and the rules governing traffic in and out of the CDE. Assessors want current firewall rule sets, network diagrams, and a change-approval log showing rule modifications went through review.

Requirement 2: Apply secure configurations to all system components. Default passwords and unnecessary services get removed before a system touches the CDE. Evidence includes configuration standards documents and build scripts or hardening checklists applied to new systems.

Requirement 3: Protect stored account data. This is one of the requirements that expanded the most under v4.0, with tighter rules on retention limits, masking, and cryptographic key management. Assessors expect a data retention and disposal policy, encryption key inventories, and proof that PAN is rendered unreadable wherever it’s stored, whether through strong cryptography or a one-way hash meeting NIST-aligned standards.

Requirement 4: Protect cardholder data with strong cryptography during transmission. TLS configuration reviews and certificate management logs are the typical evidence here.

Requirement 5: Protect systems and networks from malicious software. Anti-malware deployment reports and scan logs across all applicable systems, including those historically considered low-risk like Linux servers, satisfy this requirement.

Requirement 6: Develop and maintain secure systems and software. This includes secure coding practices and, critically, controls over payment page scripts, an area v4.0.1 clarified extensively given the rise in web-based skimming attacks. Change management records and code review logs are standard evidence.

Requirement 7: Restrict access to system components and cardholder data by business need to know. Access control matrices and periodic access reviews prove this one.

Requirement 8: Identify users and authenticate access to system components. Multi-factor authentication expanded under v4.0 to cover all access into the CDE, not just remote connections. MFA configuration exports and authentication logs are what assessors pull.

Requirement 9: Restrict physical access to cardholder data. Badge access logs and visitor logs for facilities housing in-scope systems.

Requirement 10: Log and monitor all access to system components and cardholder data. Log retention proof and evidence that logs are actually reviewed, not just collected, matters enormously here.

Requirement 11: Test security of systems and networks regularly. This covers vulnerability scans, penetration testing, and ASV quarterly scans. Scan reports and remediation tracking are the evidence trail.

Requirement 12: Support information security with organizational policies and programs. This is a governance requirement, and it picked up significant new content under v4.0 around risk analysis documentation, incident response planning, and third-party management. Policy documents, training records, and the scope confirmation itself all live here.

Requirement Objective Example Evidence
1. Network security controls Control traffic in/out of the CDE Firewall rule sets, network diagrams, change logs
3. Protect stored account data Prevent exposure of stored PAN Encryption key inventory, retention policy, hashing configuration
6. Secure systems and software Prevent exploitable code and script tampering Code review logs, payment page script inventory
8. Identify and authenticate access Confirm who is accessing the CDE MFA configuration exports, authentication logs
10. Log and monitor access Detect and investigate anomalies Log retention proof, log review records
11. Test security regularly Confirm controls work as designed ASV scan reports, penetration test results
12. Support with policies and programs Govern the overall program Risk analysis documentation, incident response plan, scope confirmation

For an e-commerce merchant using a hosted payment page, requirements 6 and 11 tend to demand the most attention, since payment page script integrity and regular scanning of the public-facing checkout flow are where skimming attacks concentrate. A brick-and-mortar merchant running point-of-sale terminals leans harder into requirements 9 and 1, physical security and network segmentation around the terminal network. A merchant relying on a third-party hosted solution still owns requirement 12 in full, since governance and vendor management responsibilities never fully transfer away.

Organizations that treat requirement 3 (stored account data) and requirement 8 (authentication) as checkbox items during initial implementation are consistently the ones that get flagged during reassessment, because both requirements demand ongoing evidence of effectiveness, not a one-time configuration.

Pro Tip: Build your evidence collection calendar around requirement 10 first. Log review is the requirement most often “met” on paper but not in practice, and it’s the fastest one for an assessor to unravel with a few pointed questions.

How Do SAQ, ROC, QSA, and ASV Validation Work?

Your validation path depends primarily on transaction volume and how you handle card data, not on how big your company feels. The four PCI compliance levels are set by the card brands based on annual transaction counts, and each level carries different expectations for how you prove compliance.

Level 1 merchants, typically those processing the highest transaction volumes, need a full Report on Compliance (ROC) performed by a Qualified Security Assessor (QSA). Levels 2 through 4 typically qualify for a Self-Assessment Questionnaire (SAQ), though card brands or acquirers can require a ROC regardless of level if risk factors warrant it. Service providers face their own tiering, and many large service providers are pushed toward ROC validation even at lower transaction volumes because of the aggregate risk they carry across multiple merchants.

The SAQ types split by how your business actually touches card data:

  • SAQ A fits merchants who fully outsource card data handling to a validated third party and never touch card data on their own systems, the lightest validation path available.
  • SAQ A-EP applies to e-commerce merchants whose website redirects to a third-party payment page but who still control some elements of the payment page itself.
  • SAQ C covers merchants with payment application systems connected to the internet, common in certain POS configurations.
  • SAQ D is the catch-all for merchants and service providers who don’t qualify for a simpler SAQ, and it covers essentially the full requirement set, making it the most demanding self-assessment.
  • SAQ P2PE-HW applies to merchants using validated point-to-point encryption hardware exclusively for card data capture.

Comparing SAQ D vs SAQ A tells you almost everything about where your scope-reduction efforts should focus: the gap between them is entirely about how much of the card data flow you touch directly. Every dollar spent on tokenization, P2PE, or gateway offload that moves you from SAQ D toward SAQ A pays back in reduced assessment burden every single year, not just once.

QSAs are individuals certified by the PCI SSC to perform ROC assessments, and their involvement is mandatory for Level 1 merchants and most large service providers. ASVs perform the quarterly external vulnerability scans required under requirement 11, and their use is mandatory for any organization with internet-facing systems in scope, regardless of SAQ or ROC status. You can find accredited assessors and scanning vendors through the PCI SSC’s own program pages, which list every currently certified QSA company and ASV.

Timelines differ sharply between paths. An SAQ, once your controls are actually in place, might take a few weeks to complete internally. A ROC engagement with a QSA typically runs several weeks to a few months, depending on environment complexity, and includes on-site or remote testing, evidence review, and a formal report the QSA submits to your acquirer. Quarterly ASV scans and any required internal scans need to happen on a fixed cadence regardless of which validation path you’re on, so build that calendar independent of your annual assessment timeline.

Pro Tip: Don’t wait until 60 days before your ROC is due to schedule your QSA. Reputable QSA firms book out months in advance, especially around calendar year-end when many merchants’ assessment cycles renew simultaneously.

How Does Continuous Testing Work Under PCI DSS 4.0?

Version 4.0’s biggest philosophical shift is treating compliance as an operating state rather than an annual event, and testing procedures reflect that directly. The standard groups new controls under the theme of continuous security, and PCI SSC has been explicit that organizations still treating compliance as a once-a-year checkbox exercise face higher audit failure risk.

Handheld scanner on network switch

Standard testing procedures haven’t disappeared. You still run authenticated internal vulnerability scans, ASV external scans quarterly, and penetration testing at least annually and after significant infrastructure changes. What changed is the documentation burden around frequency and sampling. If you want to run a control at a custom frequency rather than the default PCI-specified interval, you now need a formal Targeted Risk Analysis (TRA) justifying that choice, including the risk factors you weighed and how you arrived at your chosen interval.

The TRA guidance lays out what that documentation needs to contain: the objective being addressed, the risk factors considered, the rationale for the chosen frequency or approach, and a review cycle for revisiting the analysis. Skipping this step is one of the fastest ways to fail a control that’s technically operating fine but isn’t defensible on paper.

Acceptable continuous-evidence artifacts include automated control logs pulled directly from your SIEM or log management platform, periodic vulnerability scan reports showing a consistent cadence over time, and alerting history demonstrating that your monitoring actually triggers and gets acted on, not just configured and forgotten. A single clean scan report from three weeks before your assessment date convinces nobody; a year of consistent quarterly scans with documented remediation timelines does.

Assessors commonly request the following monitoring and testing artifacts:

  • Twelve months of ASV scan reports showing passing results or documented remediation for failures.
  • Internal vulnerability scan history at the frequency your TRA specifies.
  • Penetration test reports covering both network and application layers.
  • Log review records, not just log retention, proving someone actually examines the data.
  • Change management tickets tied to any modification of in-scope systems.

Pro Tip: Set up a quarterly internal “mock evidence pull” where your team gathers exactly what an assessor would request, six months before your real assessment. You’ll find the gaps in your evidence trail while you still have time to close them.

What Is the Customized Approach and When Should You Use It?

The Customized Approach lets you meet a requirement’s stated security objective through controls you design yourself, rather than following the prescriptive method PCI DSS spells out, as long as you can prove your alternative works just as well. It’s built into the full v4.0 standard as an explicit, sanctioned path, not a workaround.

Choosing this path means real documentation work. For each customized control, you need to map exactly which security objective you’re addressing, describe your alternative control’s implementation in enough detail that an assessor can test it, complete a Targeted Risk Analysis justifying why your approach meets the objective, and maintain ongoing evidence that the control keeps operating as designed. You also need an assessment plan spelling out how the assessor will test it, including sampling methods and the specific evidence artifacts they should expect.

That’s a lot of overhead, and it’s exactly why the Customized Approach isn’t the default choice. Many organizations find that following the prescriptive requirement outright costs less time and money than developing, implementing, and validating a custom control, even when the custom approach seems technically elegant. The Customized Approach earns its complexity when your environment has a genuinely unusual architecture, such as a highly automated infrastructure where a standard control would break existing tooling, or when you’ve already built a control for another framework, like ISO 27001, that meets the PCI objective through a different mechanism and rebuilding it the prescriptive way would be pure duplication.

Factor Prescriptive Approach Customized Approach
Documentation burden Standard testing procedures apply as written Requires objective mapping, TRA, and a custom assessment plan
Cost and time Generally lower, well-understood path Higher upfront cost; ongoing validation burden
Best fit Standard environments, typical infrastructure Unusual architectures or controls already built for other frameworks
Assessor familiarity High; assessors test against known procedures Lower; requires assessor to design and agree on new test methods

The decision usually comes down to one question: does your existing environment already produce a control that meets the objective through a different mechanism, or would you be building something custom from scratch just to avoid the prescriptive method? The first case often justifies the Customized Approach. The second case rarely does. Common pitfalls assessors flag include a TRA that describes the control but never quantifies the actual risk being managed, and an assessment plan that doesn’t specify sampling methodology clearly enough for the assessor to independently test it.

Pro Tip: *If you’re already ISO 27001 certified, audit your existing risk treatment plan before building any customized PCI control.

What Are the Most Common PCI DSS 4.0 Compliance Gaps?

The findings that recur across assessments follow a predictable pattern, and knowing them in advance lets you fix the cheap ones before they become expensive ones.

  1. Incomplete scope mapping, usually from forgetting shared services or third-party connections with unrestricted CDE access.
  2. Weak or inconsistent MFA implementation, particularly missing coverage on administrative access that isn’t remote but still touches the CDE.
  3. Missing log-retention proof, where logs exist but nobody can show a year of consistent retention and review.
  4. Untested custom controls, where a Customized Approach was adopted without a completed TRA or assessment plan.
  5. Insecure payment pages, especially unmanaged third-party scripts running on checkout pages without integrity monitoring, an area v4.0.1 clarified heavily.

Each of these fails for the same underlying reason: the control exists in some partial form, but the evidence proving it works consistently doesn’t. Assessors aren’t usually surprised by a missing control. They’re surprised by a control that’s clearly present but undocumented, because that’s what makes them start asking harder questions about everything else.

Here’s a practical remediation checklist organized by how fast each fix can realistically happen:

  • Short term (0 to 30 days): Re-run your scope mapping exercise and identify unrestricted connectivity gaps. Assign an owner, usually the security officer or IT lead, and document findings immediately.
  • Medium term (30 to 90 days): Close MFA gaps across all CDE access points and implement log review procedures with a documented cadence. Assign these to your IT operations lead with a hard deadline.
  • Long term (90 to 180 days): Complete any outstanding TRAs for customized controls and implement payment page script monitoring. This typically falls to whoever owns application security, working with your QSA if one is already engaged.

A 30/60/90/180-day template works well here: by day 30, scope and inventory are locked down; by day 60, MFA and logging gaps are closed; by day 90, evidence collection is running consistently; by day 180, customized controls are fully documented and validated ahead of assessment.

Pro Tip: If a control has genuinely been operating correctly but you never formally documented it, don’t panic and rebuild it. Gather retrospective evidence instead, log exports, ticket histories, configuration change records, anything with a timestamp, and use it to reconstruct a defensible timeline. Assessors care more about proof of consistent operation than about when you started writing it down.

Where Can You Find Official PCI DSS Resources?

Start with primary sources rather than secondhand summaries, since the interpretation gap between a blog post and the actual standard is where most compliance mistakes originate.

  • Requirements and Testing Procedures (v4.0.1) is the core document listing all 12 requirements with detailed testing procedures assessors use directly.
  • The v4.0.1 summary of changes from PCI SSC clarifies exactly what changed from v4.0, useful for confirming you haven’t missed a clarification.
  • The Quick Reference Guide (QRG) condenses the standard into a usable internal checklist format, good for briefing non-technical stakeholders.
  • Targeted Risk Analysis guidance is essential reading before adopting any custom control frequency or the Customized Approach.

For teams ready to move, here’s a five-step plan for the next 30 days:

  1. Complete or refresh your CDE scope confirmation and data-flow diagram.
  2. Inventory every in-scope system component, including third-party connections.
  3. Prioritize remediation on requirements 3, 8, and 10, since these carry the most ongoing evidence burden.
  4. Schedule your quarterly ASV scans if they aren’t already on a fixed calendar.
  5. Decide your validation path, SAQ or ROC, based on your transaction volume and current merchant level.

If you’re evaluating tools to support ongoing evidence collection, platforms built around PCI DSS compliance automation can reduce the manual burden of pulling continuous evidence artifacts every quarter. For QSA or ASV engagement, the PCI SSC program directory is the authoritative place to confirm current accreditation before signing any assessor contract.

What Do Practitioners Get Wrong About PCI DSS 4.0?

Most teams don’t fail their PCI DSS assessment because a control is missing. They fail because they can’t prove a control that’s clearly there actually works over time, and that gap trips up more organizations than any single technical weakness.

The instinct is to throw resources at the flashy stuff, encryption upgrades, new firewalls, fresh penetration tests, while scope confirmation sits untouched from three years ago. That’s backward. Scope drives everything else in the assessment. If your scope is wrong, every control you’ve built on top of it is protecting the wrong boundary, and no amount of technical sophistication inside that boundary fixes a fence drawn in the wrong place.

If I had to prioritize a limited compliance budget, I’d spend it in this order: scope confirmation and segmentation first, controls protecting PAN and sensitive authentication data second, and evidence infrastructure for continuous operation third. That third bucket is the one teams chronically underfund, and it’s also the cheapest to fix. A log retention policy and a quarterly evidence review calendar cost almost nothing compared to a new segmentation project, yet they’re what keeps an assessment from turning into a multi-week evidence-gathering scramble.

A few quick wins consistently lower audit risk fast:

  • Automate evidence collection for requirement 10 so log review has a paper trail without manual effort.
  • Run your own internal connectivity test into the CDE before your assessor does.
  • Document any control you’ve built for another framework, like ISO 27001, that might satisfy a PCI objective without duplicate work.

The organizations that struggle most under v4.0 aren’t the ones with weak technology. They’re the ones still operating on an annual compliance mindset in a standard explicitly built around continuous proof.

How Can DavinciPay Help With PCI Scope Reduction?

Reducing what falls inside your CDE is one of the fastest ways to lower both your assessment burden and your ongoing risk, and that’s exactly where Davincipay fits into your compliance strategy. Davincipay’s gateway tokenization and offload options keep raw card data off your servers, which for many merchants moves you from a demanding SAQ D toward a far simpler SAQ A or A-EP.

Davincipay

For merchants in high-risk verticals, subscription billing, telehealth, nutraceuticals, and supplements among them, Davincipay pairs that scope reduction with fraud prevention tools, chargeback mitigation, and underwriting support built for exactly these business models. Recurring billing management and structured onboarding documentation also make evidence collection easier when your SAQ or ROC comes due, since much of the transaction and system architecture detail your assessor asks for is already organized through Davincipay’s platform rather than scattered across spreadsheets. Merchants in the supplement and nutraceutical spaces, in particular, deal with compliance demands beyond PCI DSS alone, and having a payment partner that understands both layers saves real time.

If reducing your PCI scope and simplifying your compliance evidence trail sounds like the next logical step, apply now to see how Davincipay’s payment infrastructure fits your environment.

Frequently Asked Questions

What is the difference between SAQ D and SAQ A? SAQ A applies to merchants who fully outsource card data handling and never touch it directly, making it the lightest validation path. SAQ D covers merchants and service providers who don’t qualify for a simpler SAQ and must address nearly the full requirement set, making it the most demanding self-assessment option.

Who needs a QSA versus a self-assessment? Level 1 merchants and most large service providers need a Qualified Security Assessor to complete a Report on Compliance. Lower-volume merchants typically qualify for a Self-Assessment Questionnaire, though acquirers can require a ROC based on risk factors regardless of level.

Does PCI DSS 4.0.1 add new requirements? No. Version 4.0.1 is a limited revision that clarifies language and corrects errors from v4.0, and it introduces no new requirements or effective dates.

When should you use the Customized Approach instead of the prescriptive method? Use it when your environment has a genuinely unusual architecture or when you already have a control from another framework that meets the same objective. For standard environments, the prescriptive approach is usually cheaper and faster to validate.

How often do you need ASV scans? Quarterly external vulnerability scans performed by an Approved Scanning Vendor are required for any organization with internet-facing systems inside PCI scope, regardless of SAQ or ROC status.

What’s the fastest way to reduce PCI DSS scope? Tokenization, point-to-point encryption, and gateway offload for e-commerce checkout flows are the most effective scope-reduction techniques, since each removes raw card data from your own systems and shifts responsibility for direct handling elsewhere.

This article provides general information about PCI DSS 4.0 requirements and is not a substitute for guidance from a Qualified Security Assessor or your acquiring bank regarding your specific compliance obligations.

Sources