Payment Security | PCI DSS Mumbai
PCI DSS for Payment Aggregators and Fintechs in Mumbai: Scope, Timelines and Common Traps
Mumbai processes a remarkable share of India's digital payments. Payment aggregators and gateways run from Andheri and Powai, card issuers and acquiring banks sit in BKC, and a dense layer of lending platforms, wallets, neobanking apps and merchant services companies operates across the western suburbs. Any one of them that stores, processes or transmits cardholder data falls under the Payment Card Industry Data Security Standard, and for regulated payment entities the question is rarely whether PCI DSS applies but how large the resulting programme will be.
This guide explains what the standard requires, how validation paths differ for aggregators and merchants, why scope decides almost everything about cost, and the traps that most often turn a three month project into a nine month one.
Table of Contents
- What PCI DSS Asks For
- Why Payment Aggregators Face the Strictest Version
- Validation Paths Compared
- Scope Is the Whole Game
- What the Assessment Actually Examines
- Traps That Cost Mumbai Fintechs Months
- Timelines, Cost and What Recurs
- How Univate Supports Mumbai Payment Companies
- Final Thoughts
- Frequently Asked Questions
What PCI DSS Asks For
PCI DSS is maintained by the PCI Security Standards Council on behalf of the major card networks. Version 4 organises its expectations into twelve requirements covering network security controls, protection of stored account data, encryption in transit, vulnerability management, access control on a need to know basis, user authentication, physical access restriction, logging and monitoring, security testing, and an overarching information security policy supported by risk assessment, awareness training and incident response. Our breakdown of the 12 requirements covers each in detail.
Compliance is enforced contractually rather than by statute. Your obligations flow from agreements with acquiring banks, card networks and payment partners, which is why your acquirer's written instruction carries more weight than any general guidance when deciding what you must do. Our note on whether PCI DSS is mandatory in India sets out how that works.
Why Payment Aggregators Face the Strictest Version
Merchants are sorted into four levels by annual transaction volume, and smaller merchants can often validate through a self assessment questionnaire. Service providers, which is what payment aggregators, gateways and most fintech infrastructure companies are, sit in a different category with only two levels, and the larger one requires an onsite assessment by a Qualified Security Assessor resulting in a Report on Compliance.
For Mumbai's payment ecosystem this matters in a specific way. Aggregators handle card data on behalf of thousands of merchants, so banks, networks and the merchants themselves all have an interest in formal validation. A payment company's clients routinely ask for its Attestation of Compliance during onboarding, and partner banks ask for it during empanelment and at renewal. An aggregator that cannot produce one does not merely risk a penalty; it risks the commercial relationships its business depends on. Our comparison of SAQ versus QSA validation explains the difference in practice.
Validation Paths Compared
| Aspect | Merchant with outsourced payments | Merchant handling card data | Service provider or aggregator |
|---|---|---|---|
| Typical validation | Shorter self assessment questionnaire | Fuller questionnaire or onsite assessment | Onsite assessment and Report on Compliance |
| Scope | Limited, often payment page and admin access | Systems touching card data plus connected systems | Entire cardholder data environment and supporting infrastructure |
| Testing expected | Quarterly external scans | Quarterly scans plus penetration testing | Quarterly scans, segmentation testing and penetration testing |
| Who asks for proof | Acquiring bank | Acquiring bank | Banks, card networks and every merchant client |
| Typical effort | Weeks | Three to six months | Six to nine months for a first report |
Confirm your path in writing with your acquirer before budgeting anything. Choosing the wrong questionnaire is a common and expensive error, because it can leave a company attesting to a scope that does not match what it actually does.
Scope Is the Whole Game
PCI DSS applies to every system that stores, processes or transmits cardholder data, plus everything connected to those systems or able to affect their security. In a flat network where application servers, corporate laptops and office wifi share address space, the entire network becomes the cardholder data environment and every requirement applies everywhere.
Three techniques reliably shrink that footprint. Network segmentation isolates payment systems so the rest of the business falls outside scope, and segmentation testing then proves the isolation holds. Tokenisation replaces stored card numbers with tokens, so the systems referencing them no longer hold account data; Indian payment companies have already done substantial work here given the industry wide move toward tokenised card storage. Point to point encryption and hosted payment pages push card data handling onto a validated provider.
A worked example makes the difference concrete. A Mumbai platform using a hosted payment page, where card numbers never reach its own servers, may close a reduced validation in two months, with most effort going into policy work, script controls on the checkout page and tightening administrator access. The same platform storing card numbers in its own database for refunds brings that database, its backups, the application servers and everything connected into scope, and the project becomes a six month programme. Same company, same revenue, entirely different cost, decided by one architectural choice.
What the Assessment Actually Examines
Knowing what an assessor looks at removes much of the anxiety from a first engagement. They begin by validating scope, which usually means reviewing network diagrams, data flow diagrams and the evidence that segmentation works, because an understated scope invalidates everything that follows. They then test controls in the environment: whether default credentials were changed, whether stored data is rendered unreadable, whether transmission is encrypted, whether multi factor authentication protects access, and whether logs are retained and reviewed.
They sample people and process too. Expect interviews with developers about secure coding, with operations about change approval, and with support staff about how they handle a customer reading out a card number. Expect requests for scan reports, penetration test results and the remediation records showing findings were closed within the timeframes your own policy sets. Most fintechs find the evidence requests, not the technical controls, are what stretch the timeline, which is why organising evidence by requirement before the assessor arrives is time well spent.
Traps That Cost Mumbai Fintechs Months
- Budgeting before the acquirer has confirmed the validation path in writing
- Assuming a cloud provider's own compliance covers your application layer
- Leaving card numbers in logs, support tickets, email threads or analytics exports
- Treating segmentation as configured once rather than tested periodically
- Forgetting the contact centre, where agents hear card numbers and calls are recorded
- Running remediation without a named owner, which is the single commonest cause of delay
- Planning only for the first validation and not the annual revalidation that follows
The contact centre trap deserves emphasis. Many Mumbai fintechs take payments or handle disputes by phone, which brings agents' desktops, call recordings and quality monitoring tools into scope. Pause and resume recording, masked keypad entry and secure payment links are the usual remedies, and each changes scope in a different way.
Timelines, Cost and What Recurs
A well segmented environment with a reduced validation path can close in one to three months. A mid sized fintech handling card data typically needs three to six months, with remediation consuming most of it. A payment aggregator preparing a first Report on Compliance should plan six to nine months, because controls must demonstrably operate before the assessor arrives. Our cost guide explains the budget drivers.
Treat PCI DSS as a subscription rather than a purchase. Quarterly external scans, internal scans, annual testing, awareness training and annual revalidation all recur, and a budget covering only year one tends to produce an unpleasant surprise in year two. Our VAPT cost guide covers the testing side of that recurring spend.
How Univate Supports Mumbai Payment Companies
Univate scopes the cardholder data environment, confirms the correct validation path with your acquirer, closes gaps, documents policies and prepares you for scans and assessment. Our national PCI DSS practice works with payment companies across Mumbai, with local programmes also running in Ahmedabad, and our detailed India guide covers the wider process. Most payment firms run PCI DSS alongside ISO 27001, which supplies the access control, logging and incident management the standard expects, and alongside DPDP obligations that apply to the same customer data under Indian law. Payment companies with American clients often add a SOC 2 report on the same foundation, and those under scrutiny on operational resilience extend into ISO 22301 business continuity. Where several frameworks overlap, our GRC practice sequences them so one control set serves all, supported by our wider cybersecurity team.
Final Thoughts
For Mumbai's payment aggregators and fintechs, PCI DSS is part of the licence to operate commercially. The companies that find it manageable are the ones that treat scope as an engineering decision rather than a compliance one: keep card data out of systems that do not need it, segment what remains, test the segmentation, and give every remediation item an owner with a date. Do that and the annual revalidation becomes routine. Skip it and every year feels like the first.
Frequently Asked Questions
Is PCI DSS mandatory for payment aggregators in India?
It is contractually required rather than statutory. Agreements with acquiring banks, card networks and partners oblige compliance, and merchant clients typically ask for an Attestation of Compliance during onboarding, so in practice it is a condition of doing business.
What is the difference between an SAQ and a QSA assessment?
A self assessment questionnaire is completed internally and is available to many merchants. A QSA assessment is conducted onsite by a Qualified Security Assessor and produces a Report on Compliance, which is what larger service providers and aggregators generally require.
How long does a first Report on Compliance take?
Most aggregators should plan six to nine months. Controls must be implemented and demonstrably operating before the assessor arrives, and remediation rather than the assessment itself usually consumes the schedule.
Does tokenisation remove us from PCI DSS scope?
It reduces scope significantly rather than removing it. Systems that no longer store account data can fall outside the cardholder data environment, but the tokenisation process, the systems that transmit card data and everything connected remain in scope.
Do our call recordings fall in scope?
If agents can hear or see card numbers and those interactions are recorded, then yes, the recording systems and quality monitoring tools come into scope. Pause and resume recording and masked keypad entry are the usual ways to address it.
How often must we revalidate?
Annually, with quarterly external vulnerability scans required in between for most merchants and service providers. Compliance is expected to be maintained continuously, not demonstrated only at validation time.
Is our cloud provider's compliance enough?
No. A compliant cloud provider covers the infrastructure it operates, under a shared responsibility model. Your application, configuration, access control and data handling remain yours to validate.
Can PCI DSS run alongside ISO 27001?
Yes, and it usually should. Access control, logging, vulnerability management and incident response built for an ISMS cover a substantial share of PCI DSS requirements, so sequencing the two together costs considerably less than running them separately.
