PCI DSS by industry
PCI DSS for fintech and payment facilitators: service provider validation, tokenisation and cloud scope
What changes when you process card data for other businesses: why sponsor acquirers and merchants ask, what belongs in a fintech CDE, where QSAs sample across keys, APIs, cloud identities and third parties, and how PCI DSS sits beside SOC 2 and ISO/IEC 27001.
Key points
- A payment facilitator, gateway or wallet is assessed as a service provider, not a merchant: the card brands set your service provider level and your sponsor acquirer confirms whether it expects a ROC or SAQ D for Service Providers.
- Tokenisation shrinks the cardholder data environment but never removes it: the vault, the de-tokenisation service and the keys and HSMs behind them stay in scope.
- Cloud-native payment stacks fail on shared responsibility, not on the cloud provider's own AOC: your configuration, identities and pipelines are yours to evidence.
Why fintech and payment facilitators need PCI DSS
For most fintechs the request arrives through the sponsor acquirer. A payment facilitator boards sub-merchants under its acquiring relationship, a gateway transmits card data for many merchants, and a wallet or card issuing programme holds account data for a bank. In each case you process, store or transmit cardholder data on behalf of another entity, which is the definition of a service provider. The acquirer and card brands enforce compliance by contract, before onboarding and every year after.
Demand also comes from below. Merchants and platforms that route payments through your API list you as a third-party service provider in their own assessment, and requirement 12 obliges them to monitor your compliance status. They ask for your Attestation of Compliance, often before signing.
The sector is examined closely because one compromised gateway or token vault exposes every merchant behind it. The standard itself is covered in PCI DSS requirements explained, requirement by requirement.
What sits inside the scope for a fintech
A typical fintech cardholder data environment includes the payment APIs and hosted checkout, the tokenisation service and its vault, the key management service or HSMs, the connections to card networks and processors, sub-merchant onboarding and settlement systems that touch card data, the CI/CD pipeline deploying into the CDE, the identity provider and the cloud accounts hosting any of it. Support consoles that reveal a full PAN or refund to a card belong inside too.
Tokenising at the edge, isolating the vault in its own accounts and segments, and giving merchants a hosted payment page can take most of the platform out of the CDE. Whatever issues or de-tokenises stays in, and segmentation must be tested; service providers confirm scope and test segmentation more often than merchants. The method is set out in PCI DSS scoping and segmentation: shrinking the CDE.
Three scope mistakes recur in this sector: treating shared CI/CD runners or container registries as out of scope when they can change CDE workloads; forgetting fraud or analytics environments that received raw PANs before tokenisation; and validating one product while a new issuing or wallet programme runs on infrastructure the AOC does not name.
Where the requirements bite for fintech and payment facilitators
| Requirement area | What it means for a fintech | Evidence the QSA samples |
|---|---|---|
| 3 Protect Stored Account Data | Stored PAN tokenised or encrypted, no sensitive authentication data after authorisation, keys controlled in an HSM or key management service | Data discovery results, key inventory and custodian records, key rotation and access logs, retention and purge evidence |
| 6 Develop and Maintain Secure Systems and Software | APIs, SDKs and hosted checkout built securely and released through controlled change; payment page scripts authorised | Secure coding training, pipeline change records with approvals, vulnerability and patch reports, a script inventory with integrity checks |
| 8 Identify Users and Authenticate Access to System Components | Unique IDs and MFA for every engineer and cloud console session into the CDE; service accounts and API keys owned | User and service-account inventories, MFA configuration, secrets rotation records, leaver removal records |
| 10 Log and Monitor All Access to System Components and Cardholder Data | Cloud audit logs, vault access and HSM events centralised and reviewed with automated tools | Log source coverage, alert rules and daily review evidence, retention settings, records of how control failures were handled |
| 12 Policies, programmes and third parties | Processors, cloud and HSM providers managed as third parties; merchants told which requirements you meet for them | A provider register with current AOCs, responsibility matrices given to merchants, the scope confirmation, an exercised incident plan |
Requirement 11 also weighs heavily: quarterly scans, API penetration tests and segmentation testing. The full set is in the PCI DSS checklist.
How PCI DSS sits beside SOC 2, ISO/IEC 27001 and cloud controls
Sponsor banks and enterprise clients often ask for a SOC 2 report or ISO/IEC 27001 certification as well as your AOC, because PCI DSS covers card data only. None replaces another, but one control set for access, logging, change and third parties can serve all three; see PCI DSS vs ISO/IEC 27001 and SOC 2 and SOC 2 for fintech and payments.
Your cloud provider's own AOC covers the services it operates, not how you configure them: map each shared requirement in its responsibility matrix to your own control. ISO/IEC 27017, ISO/IEC 27018 and ISO/IEC 27701 add cloud and privacy controls that fit the same register.
What a fintech engagement looks like
Duration depends on the date your sponsor acquirer sets, how far tokenisation and segmentation already go, how many products and cloud accounts are in scope, and the QSA's calendar. The CTO, the security lead, the key owners, payments operations, compliance and the owner of the acquirer relationship must be involved. With Design™, Sterling guides your engineers to build and own the controls; with Drive™, Sterling carries more of the documentation, evidence and readiness testing while product teams keep shipping.
How Sterling works with fintech and payment facilitators
An AOC your sponsor acquirer and your merchants can rely on.
Our expert and experienced consultants trace every card data flow through your APIs, vault and cloud accounts, shrink the CDE before remediating it, and test each requirement the way the QSA will. Evidence lives in Effivity, included with the engagement. Sterling does not validate compliance; the QSA assesses and attests.
Book a free discovery callPCI DSS for fintech: questions buyers ask
Does a payment facilitator need a ROC or can it use an SAQ?
It depends on your service provider level, set by the card brands and confirmed by your acquirer. Mastercard, for example, requires a ROC at service provider Level 1 and accepts an SAQ at Level 2, and SAQ D for Service Providers is the only SAQ open to service providers.
If we tokenise card numbers, are we out of PCI DSS scope?
Not entirely. Systems that only see tokens can fall outside the CDE, but the tokenisation service, vault, keys and anything that can de-tokenise stay in scope.
Our cloud provider is PCI DSS compliant. Does that cover us?
No. Its AOC covers the services it operates; your configuration, identities, pipelines and data are yours to evidence, as its responsibility matrix shows.
Are our sub-merchants covered by our PCI DSS validation?
Not automatically. Your validation covers the systems and services you run for them; what each sub-merchant must validate, and how you track it, is set by your acquirer agreement and card brand rules, so confirm it with your sponsor acquirer and build the check into onboarding.
PCI DSS by industry
Every guide in the PCI DSS series is written for one question and links back to the hub for the whole picture.
- PCI DSS for banking and financial services
- PCI DSS for BPO and contact centres
- PCI DSS documentation
- PCI DSS for e-commerce and retail
- Effivity for PCI DSS
- PCI DSS for fintech and payment facilitators
- PCI DSS gap analysis
- PCI DSS for healthcare providers and insurers
- PCI DSS for hospitality and travel
- PCI DSS for software and hosting providers
Keep exploring
Explore more about PCI DSS
Watch a video on how to implement PCI DSS here.
Watch a video on PCI DSS requirements here.
PCI DSS resources
Services for PCI DSS
Talk to a consultant
Plan a PCI DSS validation your sponsor acquirer will accept.
Tell us your goals, locations and target date. We’ll help you define the scope, timeline and next steps.
hello@sterling-grc.com+1 201 263 4443 (global headquarters) · your nearest office and its number are at the top of this page
What would you like to achieve?
Choose a starting point. The enquiry form takes about a minute.
Book my free discovery callContinue to the enquiry form to share your details. Please do not include passwords, sensitive personal information or confidential files. A Sterling consultant replies within one working day. Privacy notice