Payments and Fintech
PCI DSS for Payment Aggregators and Fintechs
The Reserve Bank of India (Regulation of Payment Aggregators) Directions, 2025 require a payment aggregator to ensure merchant infrastructure meets PCI DSS and PCI-SSF where applicable, to put a bi-annual VAPT report and the PCI DSS Attestation and Report on Compliance before its IT Committee, and to have an annual system audit conducted by CERT-In empanelled auditors. Three obligations, three different answers to who may sign. SecureRoot does the testing and the readiness work behind the first two, by hand, with a retest inside the same engagement. We are not a CERT-In empanelled auditor and not a QSA, and we say which of the three you are asking about on the first call.
The Instruments
What Your Regulator and the Standard Each Require
Read the clause rather than a summary, and check the date on anything you were sent earlier: the 17 March 2020 Payment Aggregator guidelines were repealed in September 2025, so a proposal citing only those was written against a repealed document. Each row links the source.
RBI
Regulation of Payment Aggregators Directions, 2025, circular RBI/DPSS/2025-26/141, 15 September 2025
- Who it covers
- Bank and non-bank payment aggregators, online and cross-border. Paragraphs 19 to 21 and Annexure-3 carry the repeals; authorisations already granted stay valid.
- What it expects
- Para 9(a): the PA shall ensure merchant infrastructure is compliant with standards like PCI-DSS and PCI-SSF, as may be applicable. Annexure-1 para 1.5: quarterly internal and annual external audit reports, bi-annual VAPT, the PCI-DSS AOC and ROC, and the PCI-SSF status of applications handling cardholder data, all to the IT Committee. Annexure-1 para 1.18: applications built to PCI-SSF, and PCI-DSS status reviewed at merchant onboarding.
- Who it covers
- Non-bank PSOs. Footnote 2 treats payment aggregators as large non-bank PSOs, and para 3 set 1 April 2025 for large, 1 April 2026 for medium, 1 April 2028 for small. For a PA that date has passed.
- What it expects
- Para 20, sub-point 5: a PSO storing card data shall adhere to PCI-DSS guidelines and obtain PCI-DSS certification.
PCI SSC
PCI DSS v4.0.1
- Who it covers
- Anyone storing, processing or transmitting cardholder data, service providers included.
- What it expects
- The 51 requirements that were future-dated when v4.x published became mandatory on 31 March 2025 and are now assessed like any other, 6.4.3 and 11.6.1 on payment page scripts and 12.3.1 on targeted risk analyses among them.
The annual system audit under para 9(d) sits in the next band, because the question it raises is who may sign it. Two more clauses shape a scope document. Annexure-1 para 2.1: customer card credentials shall not be stored within the database or the server accessed by the merchant. Annexure-1 para 1.3: monthly cyber security incident reports with root cause analysis go to RBI, which is a notification duty rather than a testing one. PA-DSS appears nowhere in the 2025 Directions.
Services
What We Test
The Systems That Touch Card Data
The checkout and hosted payment pages, the merchant dashboard, the partner and settlement APIs, the cloud accounts and the network around them. Para 9(a) reaches merchant infrastructure too.
- Web ApplicationManual testing of your web apps against the OWASP WSTG
- APIREST, GraphQL and SOAP testing against the OWASP API Top 10
- Network InfrastructureExternal and internal network testing with lateral movement
- CloudConfiguration and IAM testing across AWS, Azure and GCP
- Mobile ApplicationAndroid and iOS app testing against the OWASP MASVS
The Controls Around the Cardholder Data Environment
Hardened configuration, a tested response, and segmentation that keeps your assessment small.
- Firewall and Perimeter ReviewRule-base and configuration review of your firewalls, VPNs and edge devices
- Cloud Security Configuration AssessmentBenchmark review of your AWS, Azure and GCP accounts against secure baselines
- Red Team AssessmentGoal-based adversary simulation across people, process and technology
When One Test Serves Several Obligations
The same testing evidences PCI DSS, the RBI VAPT line, ISO 27001 and DPDP Act safeguards. One scope, written so each reader accepts it.
Who Signs
Which Assessment Needs Whom, Including SAQ or ROC
Four obligations, four different answers. Procurement and sales both tend to collapse them into one, which is how a PA ends up buying the wrong assessment twice.
The annual system and cyber security audit
- Who may assess it
- CERT-In empanelled auditors, named in the clause.
- What that means for you
- SecureRoot does not sign this. We run the testing and the fixes ahead of it; the empanelled auditor signs the audit.
PCI DSS validation as a service provider
PCI DSS v4.0.1, ROC or SAQ D for Service Providers
- Who may assess it
- A QSA or internal security assessor producing a Report on Compliance, or self-assessment on SAQ D for Service Providers — the only SAQ a service provider may use, and only where a payment brand has defined you as eligible. The SAQs are for providers whose acquirer or brand does not require a ROC.
- What that means for you
- Your acquirer and the card brands decide, not PCI SSC and not us. Confirm it in writing before scoping, because it changes the evidence you need. SecureRoot is not a QSA.
What RBI expects to see of that validation
Annexure-1 para 1.5
- Who may assess it
- Whoever produced it; the clause is about reporting, not qualification.
- What that means for you
- The clause names the AOC and the ROC going to your IT Committee, so a PA that could self-assess under a brand programme may still need a ROC for this reporting line. Settle it before choosing a route.
The bi-annual VAPT and the risk assessment
Annexure-1 paras 1.5 and 1.1
- Who may assess it
- Para 1.5 names no empanelment. Para 1.1 allows an internal security audit, an independent security auditor, or a CERT-In empanelled auditor.
- What that means for you
- This is the work we do and sign. Independence and competence are what an inspection reads: the scope, the method, the testers' credentials and the retest record.
SecureRoot Risk Advisory LLP is not a CERT-In empanelled information security auditing organisation and not a Qualified Security Assessor. Where either signature is required, that party signs and we test beside them. Send us the clause or the acquirer's letter on the scoping call and you get an answer in that call about which of the four you are looking at.
How It Runs
Built Around the Bi-Annual Cycle
Annexure-1 para 1.5 asks for VAPT twice a year, so the engagement is scoped as a cycle rather than a one-off, with the price fixed after scoping.
01
Scope Against Your Card Data Flows and Your Acquirer's Letter
You hear back within one business day. On the call we map where card data is stored, processed and transmitted, confirm whether your acquirer requires a ROC or allows SAQ D for Service Providers, and write targets, windows, rules of engagement and the price down before anyone starts.
02
Test by Hand, External and Internal
Manual exploit-driven testing of the cardholder data environment and what connects to it, plus segmentation testing where you claim it. Every finding carries a reproduction, a justified severity and a fix naming the component to change. Critical findings reach you within three hours of discovery.
03
Close the Findings With Your Developers
The tester who found the flaw explains it to the engineer who has to change the code. Where a vendor operates the platform we need their written authorisation too, and getting it is usually the long pole.
04
Retest, Then Schedule the Second Half-Year
We retest inside the same engagement and issue a verified retest report for your IT Committee pack. The next cycle is booked from the date of this test rather than from your audit, which is how the para 1.5 cadence stays met.
Our Role
Where We Sit, and Where the Empanelled Auditor and the QSA Do
For the bi-annual VAPT and the risk assessment, empanelment does not arise. Annexure-1 para 1.1 accepts an independent security auditor, and para 1.5 names no qualification at all. That is the work we do, and we sign it.
For the annual system audit under para 9(d) a CERT-In empanelled auditor signs, and for a PCI DSS Report on Compliance a QSA does. We are neither and will not blur it. What we change is how those assessments go: the same systems tested earlier and by hand, findings proved rather than inferred, fixes closed with your developers and each one retested, so the formal cycle confirms controls that already hold.
The same testing serves the rest of the year and the rest of the programme. SecureRoot Risk Advisory LLP holds ISO/IEC 27001:2022 certification, certificate IN60432E, and one engagement produces evidence a PCI assessor, an ISO auditor and an enterprise customer's questionnaire will each accept.
Who It Is For
Who We Test For
Teams in the payment chain whose assessment scope is the business, not a side system.
Online Payment Aggregators
Authorised PAs whose checkout, dashboard and settlement APIs are the cardholder data environment.
Payment Gateways
Technology providers in the authorisation path, assessed as service providers by the merchants relying on them.
Cross-Border Payment Aggregators
PA-CB entities, now inside the same 2025 Directions rather than the repealed 2023 circular.
Fintechs on a Regulated Partner's Licence
Companies whose bank or PA partner passes its PCI and audit expectations down the contract.
Card-Linked Lending and Wallets
Flows where card data sits beside credit decisioning.
Merchants a PA Must Diligence
Platforms being onboarded, meeting para 9(a) from the other side.
Do we need a CERT-In empanelled auditor, or will an independent tester do?
Both, for different things, and the clause decides which. Para 9(d) of the 2025 Directions requires the annual system audit, including the cyber security audit, to be conducted by CERT-In empanelled auditors, with the report going to your Regional Office of DPSS at RBI. That one needs an empanelled firm and SecureRoot is not one. The bi-annual VAPT in Annexure-1 para 1.5 names no empanelment, and the risk assessment in Annexure-1 para 1.1 expressly allows an internal security audit or an annual security audit by an independent security auditor as alternatives to an empanelled auditor. So the testing that finds and closes real weaknesses can be done by an independent team, while the annual audit signature cannot. We do the former and tell you plainly which of the two you are asking about.
Is an SAQ enough, or do we need a Report on Compliance?
Your acquirer and the card brands decide, not PCI SSC and not a vendor. For a service provider there is exactly one self-assessment option, SAQ D for Service Providers, and its own instructions limit it to providers a payment brand has defined as eligible to self-assess; the SAQs are for providers whose acquirer or brand does not require a Report on Compliance. So the first thing to settle is which route your acquirer requires, in writing. There is a second consideration specific to a PA: Annexure-1 para 1.5 of the RBI Directions names the PCI-DSS Attestation of Compliance and the Report on Compliance among the documents going to your IT Committee. A PA that might have self-assessed under a brand programme can therefore still need a ROC to satisfy that reporting line. Confirm both before scoping.
Are the PCI DSS v4.0.1 requirements that were future-dated still coming?
No, they are in force. Of the 64 new requirements introduced in PCI DSS v4.x, 51 carried a 31 March 2025 effective date and were marked best practice until then. That date has passed, so they are now assessed like any other requirement. The ones payments teams feel most are 6.4.3 and 11.6.1, which cover scripts on payment pages and change and tamper detection, aimed at e-skimming, and 12.3.1, which requires targeted risk analyses. PCI SSC's own FAQ states that the v4.0.1 limited revision did not change that effective date and added no new requirements. Anything describing them as forthcoming is out of date, which matters when you are reading a scope or a gap report written a year or two ago.
What is in the engagement, and what is not?
In it: a written scope drawn from your card data flows and your acquirer's validation route, manual exploit-driven testing of the cardholder data environment external and internal, segmentation testing where you claim segmentation, a report where every finding carries a reproduction and a named fix, remediation support with your developers, and a retest inside the same engagement with a verified report for your IT Committee. The second half-year cycle is scheduled from the test date so the para 1.5 cadence holds. Not in it: the annual system audit signature under para 9(d), which needs a CERT-In empanelled auditor; a PCI DSS Report on Compliance or Attestation, which needs a QSA; your monthly incident reports to RBI under Annexure-1 para 1.3, which stay your filing. We are not a QSA and not an empanelled auditor, and we say which you need on the call.
Related Reading
Articles on PCI DSS for Payment Aggregators
- PCI DSS Compliance Checklist: The 12 Requirements Made Simple
- PCI DSS Scope Reduction: SAQ Types, Segmentation and What Auditors Check
- RBI Cybersecurity Directions 2026: What Regulated Entities Must Do Now
- CERT-In Directions Compliance in India: 6-Hour Reporting, Logs and NTP
- How Often Should VAPT Be Done? Annual Baseline, Change Triggers and Regulator Cadence in India
- API Security Testing Services: OWASP API Top 10 Coverage and Retesting
Ready When You Are
Tell us what is due and who is asking. You will leave the call with a written scope, a timeline and a fixed price, and an honest answer if we are not the right firm for it.