PCI DSS Compliance in Mumbai: QSA Audit for Banks & Fintechs
Mumbai is where India's payments industry is physically headquartered — the banks, the card networks' Indian operations, the large payment aggregators and gateways, and the RBI itself. That concentration changes what PCI DSS means for a Mumbai business. In most of the country the typical PCI question is a merchant's: "how do I avoid storing card data?" In Mumbai, a large share of the organisations asking are payment aggregators, gateways and acquiring banks — entities that process and sometimes must handle card data at the centre of the system, with the heaviest PCI DSS obligations and an RBI regulator down the road watching how they do it.
This guide is written for that reality: PCI DSS for Mumbai's payments ecosystem, where you are more likely to be a service provider than a simple merchant, where RBI's payment-aggregator and tokenisation rules sit on top of the card-brand standard, and where the volume of transactions makes scope the defining problem. For the general mechanics of the 12 requirements and the 4.0.1 changes, see our PCI DSS compliance guide; here the focus is Mumbai's service-provider and BFSI angle.
Merchant or service provider — the distinction that defines your obligation
PCI DSS treats these two very differently, and Mumbai has an unusually high proportion of the second:
- Merchants accept cards for their own sales. Most can minimise scope by outsourcing card capture and never touching the card number — landing on a simpler validation path.
- Service providers — payment aggregators, payment gateways, processors, and hosting providers that store, process or transmit card data on behalf of others — carry the stricter obligations. They typically need a QSA-led Report on Compliance regardless of volume, must meet service-provider-specific requirements (including more frequent testing and reporting), and are the entities whose compliance everyone downstream depends on.
- Acquiring and issuing banks sit at the centre with the fullest obligations and RBI oversight on top.
If you are a Mumbai payments business, the first question is which of these you are — because it determines whether you self-assess or face a full QSA assessment, and whether the service-provider clauses of PCI DSS apply to you. Many fintechs discover they are service providers in PCI terms without having thought of themselves that way.
RBI sits on top of PCI DSS here
For a Mumbai payments business, PCI DSS is necessary but not sufficient — RBI adds a layer the card-brand standard does not:
- Payment Aggregator / Payment Gateway rules: RBI's framework requires PA authorisation, prescribes governance and security baselines, and mandates security audits — PCI DSS compliance is effectively an entry condition, not the whole requirement.
- Card-on-file tokenisation (CoFT): RBI restricts who may store actual card numbers. Merchants and most aggregators must tokenise card-on-file data rather than store PANs. This both shapes your architecture and, helpfully, shrinks the PCI DSS scope for those who hold tokens instead of card numbers.
- Data storage and localisation: RBI's payment-data storage rules require certain payment data to be stored in India, which interacts with how and where you build your cardholder data environment.
- System audit / security audit expectations: RBI-regulated payment entities face their own audit cadence, which runs alongside the PCI DSS assessment rather than replacing it.
The net effect: a Mumbai payments business is usually solving PCI DSS and RBI obligations together, and the smart architecture (tokenise, don't store; localise; segment) satisfies both at once.
At Mumbai's volumes, scope is the whole game
The transaction volumes that flow through Mumbai's payments infrastructure make the cardholder data environment large and the cost of getting scope wrong severe. Two levers dominate. First, tokenisation — holding tokens rather than PANs removes systems from scope entirely, which RBI's CoFT regime pushes you towards anyway. Second, segmentation — isolating the CDE from the rest of the network so the bulk of your systems fall outside PCI DSS, proven by segmentation penetration testing under Requirement 11. For a high-volume Mumbai processor, the difference between a well-segmented CDE and a flat network is the difference between a manageable assessment and an unmanageable one. This is also where a scan-and-ship vendor most often fails: Requirement 11 demands real penetration testing and segmentation testing, not an automated scan.
Frequently asked questions
FAQs
Are we a merchant or a service provider under PCI DSS?
If you store, process or transmit cardholder data on behalf of other businesses — as a payment aggregator, gateway, processor or card-data host — you are a service provider, with the stricter obligations (usually a QSA-led Report on Compliance regardless of volume, plus service-provider-specific requirements). If you only accept cards for your own sales, you are a merchant. Many Mumbai fintechs are service providers in PCI terms without having classified themselves that way — getting this right is the first step.
Does PCI DSS cover our RBI payment-aggregator obligations?
No — they sit on top of each other. RBI's PA/PG framework requires authorisation, governance and security audits, and treats PCI DSS compliance as effectively an entry condition rather than the whole requirement. You need to satisfy both, and RBI's tokenisation and data-localisation rules shape the architecture you build to do so.
Can we store card numbers if we're a Mumbai aggregator?
Generally no. Under RBI's card-on-file tokenisation regime, most merchants and aggregators cannot store full card numbers and must tokenise card-on-file data. This is a constraint, but it works in your favour on PCI DSS — holding tokens instead of PANs removes systems from your cardholder data environment and shrinks the assessment.
Why does scope matter so much at our volumes?
The cardholder data environment is every system that stores, processes or transmits card data plus everything connected to it. At Mumbai payment volumes, a flat network puts almost everything in scope and makes the assessment enormous. Tokenisation and network segmentation pull the majority of systems out of scope — the single biggest lever on both cost and risk — provided the segmentation is proven by penetration testing, not just asserted.
Does PCI DSS Requirement 11 need real penetration testing?
Yes. Requirement 11 mandates internal and external vulnerability scanning and penetration testing of the CDE, plus segmentation testing to prove your scope reduction actually holds. An automated scan does not satisfy it. This is the requirement a scan-and-ship vendor most often gets wrong, and for a high-volume processor it is central, not peripheral.
The bottom line
For a Mumbai payments business, PCI DSS is rarely a simple merchant exercise — you are likely a service provider, carrying the heavier obligations, with RBI's payment-aggregator, tokenisation and localisation rules layered on top. Win it by classifying yourself correctly, tokenising and segmenting to control scope, and proving that scope with real penetration testing under Requirement 11. CyberSigma runs PCI DSS scoping, QSA-led assessment and CDE penetration testing for Mumbai's aggregators, gateways and BFSI entities — aligned with the RBI obligations you answer to in parallel. Book a free scope review to find the shortest honest path to your attestation.
Liked the post? Share on:
Leave A Comment