What should acquiring banks do first when merchants are struggling to meet PCI DSS requirements at scale?

Acquiring banks should start by assessing which merchant segments create the highest compliance and fraud exposure, then offer a managed path that reduces the burden of controls, reporting, and remediation. The practical goal is to keep merchants processing payments while improving baseline security, rather than leaving them to absorb fines, operational disruption, and avoidable exposure on their own.

Start with the merchant segments that drive the most exposure

When merchants are failing to keep up with PCI DSS at scale, the first move is not to launch a broad remediation program for everyone at once. Acquiring banks need a segmented view of which merchant groups create the highest combined compliance, fraud, and operational risk, then focus on the accounts where a control gap would have the largest downstream effect on payment acceptance and security posture.

That triage matters because merchant populations are rarely uniform. A large low-risk merchant base may need light-touch support, while a smaller set of higher-volume or higher-risk merchants may justify closer oversight, faster escalation, and more structured remediation paths. For payment ecosystems, the question is which accounts can most safely continue processing while the bank reduces exposure first.

For payment-sector control mapping, the compliance baseline and access discipline in PCI DSS v4.0 are the clearest external reference point. Where merchant controls are stretched, the practical lens is to rank the population by exposure, then apply the most intensive support where it changes the risk profile fastest.

Offer a managed path instead of leaving merchants to self-remediate

Once the highest-risk segments are identified, acquiring banks should give merchants a managed route that lowers the burden of reporting, evidence collection, and remediation. That can include templated control packs, centralized guidance, shared assessment workflows, and clearer support for recurring failure points such as account governance, access reviews, and evidence retention.

The objective is not to weaken the standard, but to make compliance achievable without forcing every merchant to build the same security capability from scratch. In practice, banks often become the coordinating control point, especially where merchants lack mature security staff or where the cost of bespoke remediation would push them out of the payment program entirely.

That managed approach aligns with the broader identity and access discipline in Identity Security Regulatory Map and with the audit and governance focus in Ultimate Guide to NHIs, Regulatory and Audit Perspectives, because the recurring problem is not just policy existence, but whether the merchant can demonstrate controlled access, accountability, and evidence at scale.

Keep merchants processing while reducing the chance of avoidable failure

The first bank-level decision is usually continuity, not punishment. If merchants are failing PCI DSS because controls are fragmented or too costly to implement all at once, an acquiring bank should preserve payment processing where possible while tightening the riskiest gaps in a sequenced way. That avoids a binary outcome where merchants either ignore the program or absorb avoidable disruption.

This is especially important when compliance work is tied to revenue flow. If the bank pushes too hard, merchants may delay remediation, degrade reporting quality, or create hidden workarounds. If the bank provides a phased route, it can improve baseline security while maintaining business continuity and keeping the merchant inside the control perimeter.

A useful comparison point is the formal control structure in NIST SP 800-53 Rev 5 Security and Privacy Controls, which reinforces the value of access control, auditability, and repeatable governance when compliance must be operationalized across many external parties.

Risk and Threat Considerations

Merchant compliance failure is not only a standards problem, it can become an exposure problem for the acquirer. Weakly governed merchants can increase fraud losses, create reporting blind spots, and leave the acquiring bank carrying more of the operational and reputational impact if breaches or payment disruptions occur across multiple accounts.

Failure mechanism: The bank treats all merchants the same, so the highest-risk accounts keep the same weak controls, the same evidence gaps, and the same remediation delays. That creates clustered exposure, especially where payment access remains live while security posture stays poor.

Impact: The acquirer inherits avoidable concentration risk, continued non-compliance, and a higher chance of business interruption or fraud escalation. The longer the bank waits to segment and manage the problem, the more likely remediation becomes reactive, expensive, and disruptive.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while PCI DSS v4.0 defines the regulatory obligations.

Framework	Control / Reference	Relevance
PCI DSS v4.0	Req. 7 — Restrict access to system components and cardholder data by business need to know	Merchant-scale compliance failures often expose access governance gaps.
	Req. 8 — Identify users and authenticate access to system components	Merchant programs at scale often fail when accounts, credentials, and authentication are poorly governed.
Recommendation — Prioritise merchant controls that enforce least-privilege access and reduce unnecessary account exposure. Tighten merchant account authentication and lifecycle control before expanding the remediation scope.
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	Acquirers need a risk-based way to segment merchants and focus effort where exposure is highest.
	PR.AA-05 — Manage Credentials for Assets and Users	Scaled merchant support depends on controlling credentials and access paths across many accounts.
Recommendation — Rank merchants by compliance and fraud exposure, then route the highest-risk segments into managed remediation. Review credential and access governance for merchant-facing systems before relying on self-remediation.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Managed merchant access should reduce unnecessary privilege and limit blast radius.
Recommendation — Apply least-privilege access patterns to merchant-support and payment-facing systems.

Practitioner Guidance

What to prioritise: Start with merchants whose transaction volume, fraud history, access complexity, or remediation lag would create the greatest combined exposure if left unmanaged. That is usually the fastest path to reducing systemic risk without forcing a wholesale program rebuild.

What to verify: Confirm that the bank can distinguish between merchants that need education, merchants that need structured remediation support, and merchants that present an exception risk requiring escalation. If that distinction is missing, the bank cannot scale the program responsibly.

Practitioner takeaway: The right first step is segmentation plus support, not blanket enforcement. Acquirers that reduce the hardest compliance burden first usually improve security faster than those that treat every merchant as the same remediation problem.