Payment Service Providers and fintech companies operating payment infrastructure face the most demanding PCI DSS compliance obligations in the ecosystem. As service providers, they are subject to stricter validation requirements, must demonstrate compliance to their merchant customers, and — if Level 1 — must appear on card network compliance registries. The intersection with Indonesian payment regulation adds additional layers that distinguish PSP compliance from a simple PCI DSS implementation.
PSP Classification — What Type Are You?
Under PCI DSS, a service provider is any entity (other than a card brand) that processes, stores, or transmits cardholder data on behalf of another entity, or that could impact the security of that entity's cardholder data. Indonesian fintech companies commonly fall into these service provider categories:
| PSP Type | PCI DSS Classification | Typical Scope | Validation Requirement |
|---|---|---|---|
| Payment gateway | Service Provider | All systems processing card authorization and tokenization flows | Level 1 or Level 2 SP depending on volume; ROC or SAQ D-SP |
| Payment processor | Service Provider | Card processing infrastructure, settlement systems, reconciliation | Level 1 SP; ROC required |
| Tokenization service provider | Service Provider | Token vault, token-to-PAN mapping, token issuance APIs | Level 1 SP; ROC required; card network listing |
| Hosted payment page provider | Service Provider | Payment page infrastructure, merchant credential management | Level 1 SP; ROC required |
| Payment orchestration platform | Service Provider (if handles CHD) | Multi-PSP routing layer — if routes raw PANs, SP obligations apply | Scope depends on whether CHD is handled or tokens only |
| Digital wallet provider | Service Provider / Network Operator | Depends on wallet architecture and card brand relationships | Varies by card brand program rules |
Service Provider Validation Requirements
Service provider validation is stricter than merchant validation at equivalent volumes. Level 1 service providers (over 300,000 Visa/MC transactions annually) must: complete an annual Report on Compliance (ROC) with a QSA, pass quarterly ASV external scans, submit the AoC to their sponsoring financial institution, and — for Visa and Mastercard — appear on the respective compliance registries.
| KEY IDEA | Service providers must not only be PCI DSS compliant themselves — they must also demonstrate their compliance to each of their merchant customers. Enterprise merchants increasingly require a current, valid service provider AoC as a condition of onboarding. Being on the Visa Global Registry of Service Providers is effectively a market access requirement for Indonesian PSPs targeting large merchants and international acquirers. |
PCI DSS v4.0 — Service Provider-Specific Requirements
Several v4.0 requirements are specific to or more stringent for service providers:
- Requirement 3.3.3: Service providers must not retain SAD for any customer — even if the customer requests it (exception for issuers with documented business justification)
- Requirement 8.6.3: Passwords for service accounts with access to customer CDEs must be changed at least once per 12 months and if compromised
- Requirement 12.9.1: Service providers must provide written acknowledgment to customers that they are responsible for the security of cardholder data they possess, store, process, or transmit on behalf of the customer
- Requirement 12.9.2: Service providers must support customers in confirming compliance — providing current AoC, clarifying shared responsibility, and notifying customers of changes affecting their compliance
Shared Responsibility — What PSPs Are Responsible For
A core PCI DSS obligation for service providers is clearly communicating which PCI DSS requirements they are responsible for and which their merchant customers are responsible for. This is documented in the Responsibility Matrix (sometimes called the Responsibility Summary in the AoC).
| Control Domain | PSP Responsibility | Merchant Responsibility |
|---|---|---|
| Network security (hosted environment) | PSP manages firewall and NSC for hosted payment infrastructure | Merchant manages their own network outside the PSP-hosted CDE |
| Encryption at rest (PSP's vault) | PSP responsible for PAN encryption and key management | Merchant responsible for any CHD they store separately |
| Access control (PSP systems) | PSP manages access to the shared payment platform | Merchant manages access to their own merchant portal and integrations |
| Security testing | PSP performs penetration testing of shared infrastructure annually | Merchant responsible for their own systems and custom integrations |
| Incident response | PSP notifies merchants of any breach affecting their CHD | Merchant responsible for their own incident response and customer notification |
BI PBI 23/2021 — The Indonesian Regulatory Overlay
Bank Indonesia's Peraturan Bank Indonesia (PBI) 23/2021 on Payment Systems establishes security requirements for payment system operators (PSO) that align significantly with PCI DSS. Key PBI 23/2021 requirements that overlap with PCI DSS:
- Information security management system requirements (ISO 27001 or equivalent)
- Data protection requirements for payment data (aligning with PCI DSS Req 3 and 4)
- Incident reporting to Bank Indonesia within 24 hours of a payment security incident
- Regular security testing (penetration testing, vulnerability assessment)
- Business continuity and disaster recovery for payment systems
- Third-party risk management for payment system operators
| IMPORTANT | PSOs regulated by Bank Indonesia are required to report security incidents to BI within a defined window — currently 24 hours for major incidents. This is stricter than the PCI DSS requirement, which requires immediate notification to your acquiring bank. Indonesian PSPs must ensure their incident response plan covers both the PCI DSS card network notification chain AND the BI incident reporting obligation. |
Building a PSP Compliance Program in Indonesia
Recommended sequence for Indonesian fintech and PSP organizations: engage a QSA with Indonesian market experience, conduct scope definition with explicit BI/OJK regulatory context, implement ISO 27001 and PCI DSS as parallel tracks (significant evidence overlap), engage the card networks (Visa, Mastercard) for service provider program enrollment, and apply for the Visa Global Registry once the first ROC is complete.
| Bitlion has supported multiple Indonesian PSPs through their first PCI DSS ROC assessment. The recurring challenge is not technical maturity — Indonesian fintech engineering teams are sophisticated — but compliance documentation and process discipline. The QSA will ask for evidence of every control operating over a 12-month period. Indonesian PSPs that invest early in GRC tooling and evidence management finish their first ROC assessments significantly faster than those that try to gather evidence manually in the weeks before fieldwork. |