Why Acquirers Run Their Own PCI Review
Card scheme rules (Visa, Mastercard) require merchants and payment facilitators to achieve PCI DSS compliance. But acquirers carry the financial liability when a breach occurs — they are fined by card schemes and bear chargeback costs. As a result, most tier-1 acquirers operate compliance teams whose assessment criteria go beyond what PCI DSS requires:
Liability is theirs
Card scheme fines for a data breach flow to the acquirer first. The acquirer then seeks indemnity from the merchant — but in fintech failures, recovery is often partial or nil.
Scheme rules are a floor
Visa and Mastercard compliance programmes set minimum requirements. Acquirers add their own controls on top — residual liability stays with them regardless of scheme certification.
Ongoing monitoring
Acquirers do not just check compliance at onboarding. Monthly transaction monitoring, annual re-review, and triggered deep-dives are standard for fintech merchants above threshold volumes.
The Acquirer Onboarding Review: What Gets Checked
At onboarding, an acquirer's merchant risk and compliance team will request a documentation pack and run technical checks. The following is what a fintech merchant or PayFac should expect — and what a QSA should ensure is in order before the acquirer review begins.
Stage 1: Documentation Pack Review
01
Current ROC or SAQ with QSA attestation
The acquirer requires a valid Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ) signed by a QSA. "Valid" means dated within 12 months. An expired ROC is treated as non-compliant regardless of the underlying controls state. The acquirer's team will check the assessment date on the Attestation of Compliance (AOC), not the document body.
02
Network segmentation evidence
For AWS-hosted entities, this means a current network diagram showing CDE isolation, VPC boundaries, and the flow of cardholder data. Acquirers flag diagrams that show flat networks, missing subnet labels, or CDE components co-located with non-CDE workloads without documented segmentation controls.
03
Third-party service provider (TPSP) list with PCI status
Acquirers require a list of all TPSPs that process, store, or transmit CHD — including payment gateways, tokenisation providers, hosted fields vendors, and cloud providers. Each TPSP must have a current Mastercard or Visa-registered PCI DSS certificate, or the entity must have evidence of the TPSP's compliance in the absence of scheme registration.
04
Incident response plan
Acquirers require the incident response plan to contain the acquirer's notification contact details and a defined notification timeline. Most acquirers require notification within 24–48 hours of confirmed or suspected breach — faster than the PCI DSS 72-hour requirement. Plans that do not name the acquirer are rejected.
05
Penetration test report (within 12 months)
The pen test report must be scoped to the CDE and signed by a named tester. Acquirers increasingly require evidence that findings from the pen test were remediated, not just that the test was performed. A pen test with open critical findings will trigger an escalated review.
Stage 2: Technical Due Diligence
Beyond documentation, larger acquirers conduct or commission technical reviews. These are distinct from the PCI DSS assessment and focus on live environment configuration. The following table shows the most common technical checks and what a failing finding looks like:
| Check | Method | Pass criteria | Common failure |
|---|---|---|---|
| TLS configuration on payment endpoints | SSL Labs or equivalent scan of payment-facing domains | TLS 1.2+ only; no weak ciphers; valid certificate chain | TLS 1.0/1.1 still accepted on legacy API endpoints not covered by the main domain scan |
| DNS and certificate management | Certificate transparency log check; DNSSEC status | No expired or expiring-within-30-days certificates; DNSSEC enabled on payment domain | Wildcard certificates covering both payment and non-payment subdomains — CDE scope ambiguity |
| Public IP exposure of backend services | Shodan/Censys scan of ASN or IP range | No RDS, Elasticsearch, admin ports exposed on public IPs | Admin console accessible on non-standard port — not caught by standard port scans |
| PAN in web traffic | Passive scan of checkout flow for PAN in URL params or referrer headers | No PAN in URL, referrer, or analytics payloads | Google Analytics / Tag Manager receiving page URLs that include partial PAN |
| Payment page script integrity | Browser inspection of payment page CSP and script loading | SRI hashes on all payment scripts; strict CSP; no inline scripts | CSP present but in report-only mode — provides no actual protection |
| 3DS implementation | Transaction test against 3DS endpoint | 3DS2 frictionless and challenge flows functioning; fallback to 3DS1 documented | 3DS implemented for EU only — US transactions bypass 3DS entirely |
PayFac-Specific Requirements
Payment facilitators face additional scrutiny because they are responsible for the PCI DSS compliance of their sub-merchants. An acquirer onboarding a PayFac will assess the PayFac's programme as well as its own environment:
- Sub-merchant onboarding controls: Does the PayFac conduct due diligence on sub-merchants before boarding? Acquirers expect a documented onboarding questionnaire and a risk-based approval process.
- Sub-merchant monitoring programme: Is there an ongoing monitoring process for sub-merchant transaction anomalies? Acquirers expect automated monitoring with defined escalation thresholds.
- Sub-merchant breach notification: Does the PayFac's contract with sub-merchants require notification within the acquirer's window? PayFac agreements that allow 72+ hours will be flagged.
- Responsibility matrix: Is there a documented responsibility matrix showing which PCI DSS requirements the PayFac covers, which the sub-merchant covers, and which are shared? Acquirers expect this to be included in sub-merchant agreements.
- Sub-merchant SAQ oversight: Does the PayFac track sub-merchant SAQ completion and expiry? Acquirers expect the PayFac to maintain a register of sub-merchant compliance status.
Ongoing Monitoring: What Triggers an Acquirer Deep-Dive
Acquirer compliance monitoring does not end at onboarding. The following events typically trigger an unscheduled review or restrictions on processing volumes:
Chargeback ratio above threshold
Visa and Mastercard have published chargeback thresholds (typically 1% for Mastercard, 0.9% for Visa). Acquirers often trigger review at 0.5–0.75% — before scheme penalties apply — because the acquirer pays the scheme fine, not the merchant.
Suspected or confirmed breach
Any notification to the acquirer of a suspected breach — including from a third party such as a card brand compromise alert — triggers mandatory forensic investigation (PFI engagement) within 24 hours. The acquirer suspends processing pending investigation outcome.
Expired AOC
Most acquirers run automated AOC expiry tracking. An expired certificate generates an automatic non-compliance notice and, after a defined cure period, processing restrictions. The cure period is typically 30–90 days depending on the acquirer.
Significant architecture change
Notification of a major architecture change — new cloud region, new payment processor, acquisition of another entity — triggers a re-scoping review. Acquirers expect notification before go-live, not after. See our article on re-assessment triggers for full detail.
Adverse media or regulatory action
A regulatory fine, ICO enforcement notice, or adverse press coverage related to data handling triggers an unscheduled compliance review regardless of PCI DSS status. Acquirers treat reputational risk as compliance risk.
Change of ownership or key personnel
Acquisition, merger, or change of CISO/DPO triggers re-review of information security programme. The incoming acquirer in an acquisition scenario typically requires a new AOC within 90 days of close.
Preparing Your Client for Acquirer Review
A QSA supporting a fintech through acquirer onboarding should prepare the following beyond the standard PCI DSS assessment deliverables:
| Deliverable | Why acquirers require it | Common QSA omission |
|---|---|---|
| Executive summary of controls environment | Acquirer compliance teams are not technical — they need a plain-language summary of what is in scope, what controls exist, and what the residual risk is | QSA produces ROC only — no executive summary; acquirer escalates to technical review unnecessarily |
| Scoping justification document | Acquirers want to understand why certain systems are out of scope — especially cloud-managed services the entity relies on | Scope is documented in ROC but the rationale for exclusions is not extracted into a standalone document |
| TPSP compliance register | A table of all TPSPs with their PCI DSS certificate date, scheme registration status, and the services they provide | TPSP list included in ROC appendix but certificate dates not verified or are expired |
| Remediation closure evidence | For any findings from the assessment or pen test — evidence of closure, not just a remediation plan | Remediation plan submitted; acquirer expects evidence of implementation (screenshots, Config rule outputs) |
| Acquirer notification contact in IRP | The incident response plan names the acquirer's compliance contact and notification timeline | IRP references "payment processor" generically — acquirer contact not named |
QSA note: The most common reason fintech merchants fail acquirer review is not a failed PCI DSS control — it is missing or incomplete documentation. An acquirer's compliance team works to a checklist, not a controls framework. If the document is absent, the control is assumed non-existent regardless of technical reality.
Interactive assessment
Apply this in your assessment
This assessment maps directly to the controls in this article. Use it to generate gap evidence, cardholder data flow diagrams, or scoping documentation for a PCI DSS assessment — free with a Sync Your Cloud account.
Acquirer Readiness Tool
Generate an acquirer-ready compliance pack — including scoping justification, TPSP register, SAQ selection rationale, and an executive summary structured to answer the questions acquirer compliance teams actually ask.