PCI DSS and the RBI Payment Aggregator Directions, 2025: clause by clause

The Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025 — RBI/DPSS/2025-26/141, issued 15 September 2025 and effective immediately — name PCI DSS in four places. Not one of them says a payment aggregator must hold a PCI DSS certificate. Read together they ask for something harder to fake: that a PA can show its board committee, and RBI, that it knows the PCI DSS status of its merchants, its payment applications and itself — and has closed what it found.

The four clauses that name PCI DSS

Annexure 1 is not advisory for a PA: its preamble makes the baseline technology-related recommendations mandatory for PAs and recommended for payment gateways.

If your copy says PA-DSS, your copy is wrong

All four clauses say PCI-SSF. Several summaries published in September and October 2025 quote them as PA-DSS, as does at least one mirrored copy of the PDF. PA-DSS — the Payment Application Data Security Standard — was retired by the PCI Security Standards Council on 28 October 2022 and replaced by the Software Security Framework. A pack that cites PA-DSS today names a standard nobody can validate against. Check your extract against the text on rbi.org.in.

9(a): the obligation runs down the chain, and PCI DSS runs up it

PCI DSS makes an entity responsible for the service providers above it. Requirement 12.8.1 requires a list of all third-party service providers “with which account data is shared or that could affect the security of account data” — its examples name payment gateways, processors and payment service providers. Requirement 12.8.4 requires a programme to monitor those TPSPs' PCI DSS compliance status at least once every 12 months, and 12.8.5 a record of which requirements each party manages. Requirement 12.9.2 obliges the TPSP to hand that over on request.

Clause 9(a) points the other way: it makes the PA responsible for the merchants below it. Along a single PA-to-merchant relationship the two instruments impose mirror-image duties — under PCI DSS the merchant must know the PA's status, under the Directions the PA must know the merchant's. A PA that has built only the PCI DSS side — a TPSP register pointing at its acquirers and cloud providers — has built half the control it must hold.

“As may be applicable” is not a let-out. Applicability under PCI DSS is a function of the merchant's level and validation route, set by the payment brands and applied through the acquirer, not chosen by the PA. The standard's applicability note to 12.8.1 forecloses the convenient reading in both directions:

“The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity's responsibility for its own PCI DSS compliance.”

A merchant cannot shelter behind the PA's compliance, and the PA cannot offer its own AOC as evidence that it has discharged 9(a).

§1.4 and §1.18: onboarding is where 9(a) is discharged

Clause 9(a) is continuous, but the Annexure puts the mechanism at one point in the lifecycle. Section 1.4 requires a “comprehensive security assessment during merchant onboarding process to ensure these minimal baseline security controls are adhered to by the merchants”. Section 1.18 adds the specific test: “review PCI-DSS compliance status as part of merchant onboarding process”. Two clauses, one process — and the artefact that answers both is the merchant's own AOC, or, where a merchant has never validated, the absence of one and a documented plan. It is PCI DSS 12.8.4's monitoring programme aimed downstream: a PA already running one has the machinery, lacking only the merchant-facing instance.

§1.5: the IT Committee pack, itemised

Section 1.5 is the sharpest clause in the Annexure: it lists artefacts, not principles. The entity must submit to the IT Committee:

• quarterly internal audit reports;
• annual external audit reports;
• bi-annual Vulnerability Assessment / Penetration Test (VAPT) reports;
• a “PCI-DSS including Attestation of Compliance (AOC) and Report of Compliance (ROC) compliance report with observations noted if any including corrective / preventive actions planned with action closure date”;
• an inventory of applications which store, process or transmit customer sensitive data;
• PCI-SSF compliance status of payment applications which store or process cardholder data.

RBI writes “Report of Compliance”. PCI SSC writes Report on Compliance. Same document — worth knowing before someone hunts for an artefact that does not exist.

Naming both the AOC and the ROC presumes a validation route that produces both. A ROC is the output of an assessment by a QSA or an ISA; an entity validating by self-assessment produces an SAQ and an AOC, and no ROC at all. If your PA validates by SAQ, the pack has a named line item it cannot fill, and the minutes should say why rather than leave a gap. What each artefact is, and who signs it, is the prior question.

The clause does not stop at the report. It asks for observations, corrective and preventive actions, and an action closure date. An AOC carries none of those — it summarises outcome, not findings. This is where packs most often fail: the certificate-shaped document is filed and the finding register behind it is not.

On cadence, §1.5 asks for VAPT twice a year while PCI DSS Requirements 11.4.2 and 11.4.3 set a floor of once every 12 months and after significant change. A PA is also a service provider under PCI DSS, which brings 11.4.6 — segmentation testing at least once every six months — into the same rhythm. The two clocks, and how to scope against the tighter one, is a subject of its own.

9(d): the CERT-In empanelled system audit is a separate instrument

Clause 9(d) requires “an annual system audit, including cyber security audit, conducted by CERT-In empanelled auditors”, with the report submitted to the respective Regional Office of DPSS, RBI within its prescribed timelines.

It is routinely conflated with Annexure 1 §1.1, which governs the comprehensive security risk assessment and accepts a wider set of providers — “an internal security audit or an annual security audit by an independent security auditor or a CERT-In empanelled auditor”. Clause 9(d) is narrower: that audit is a CERT-In empanelled engagement, and its report goes to RBI rather than the board.

Nor is it a PCI DSS assessment: different qualification, different scope, different recipient, and it produces neither an AOC nor a ROC. A PCI DSS assessment does not answer 9(d) either. What the two share is evidence — asset inventory, scan and test results, finding registers with closure dates — so the economy is to scope the technical testing once and let both consume it. The bi-annual VAPT in §1.5, the Requirement 11.4 penetration tests and the segmentation testing under 11.4.5 and 11.4.6 are one body of work if scoped once against the documented CDE, and three arguments if not. What gets a PCI penetration test report rejected applies with equal force to a report an IT Committee has to accept.

Security Brigade is CERT-In empanelled and works with RBI-regulated payment aggregators on the testing side of these obligations — penetration testing and system audit for payment aggregators.