I’m often asked whether PCI DSS apples to entities involved in Open Banking, particularly Payment Initiation Service Providers1 (PISPs) who may receive PAN as part of a payment reference and Account Servicing Payment Service Providers2 (ASPSPs) who may receive that reference from a PISP.
Between working at Visa and Mastercard on PCI standards, I worked in the legal team at the Open Banking Implementation Entity for a couple of years as the data protection specialist there. This question came up quite frequently, and I still get asked it today. My answer is based on UK/EU law and, as I’m not a lawyer, if you want legal advice you should ask a lawyer. The TL;DR is:
Open Banking PISPs and ASPSPs cannot require PCI DSS compliance of each other because by design PSD2 does not provide for contractual obligations between Open Banking participants.
1. Compliance with PCI DSS is generally a contractual obligation
PCI DSS compliance is not a legal or regulatory requirement. Just because an entity stores, processes or transmits cardholder data doesn’t mean it has to comply with PCI DSS.
An entity only has to comply with PCI DSS if it signs a contract with another entity, and that contract mandates PCI DSS compliance.3
Typically contracts like this are between:
A card brand and an issuer
A card brand and an acquirer
An acquirer and a merchant
An issuer or acquirer and a service provider
A merchant and a service provider
2. Open Banking is a contract-free zone
Open Banking was established to create an ecosystem that does not require contracts between PISPs and ASPSPs. If it didn’t take this approach, every PISP would have to contract with every ASPSP – which would be millions of contracts. The clue is in the name: Open Banking.
So PSD24 (and in the UK, the PSR5) created an ecosystem where the regulator creates the environment that means an ASPSP can “trust” a PISP, because the PISP is regulated by the competent national authority (in the UK, the FCA). A PISP can pass a payment instruction to an ASPSP without a contract.
There is no contract between a PISP who wants to send an ASPSP a payment instruction, therefore the PISP has no mechanism to require the ASPSP to do anything other than what PSD2 says. The PSIP cannot impose extra conditions (such as compliance with PCI DSS) on the ASPSP, and equally the ASPSP cannot impose extra conditions on the PISP.
The security required to participate in Open Banking is defined by the EBA6 via Regulatory Technical Standards (not the card brands) and the ASPSP or PISP may provide an attestation of its security posture to the competent national authority. See Article 95 of PSD2.
3. No contract means no PCI compliance obligations apply
The above two points are why a PISP cannot require an ASPSP to comply with PCI DSS if the PISP wants to include a PAN as a reference field in a payment instruction, and an ASPSP cannot make a similar demand for PCI DSS compliance from a PISP.
Aside from the contract vs regulation issue, requiring any special protection for account numbers goes against the whole philosophy of PSD2.
3.1 An account number is not a payment instrument (in PSD2)
The whole PISP and ASPSP ecosystem relies on using account numbers as identifiers. PSD2 takes care to make sure an account number is not a proxy for a payment instrument and so it doesn’t require any special protection. PSD2 assumes an account number is not sensitive because all payment instructions are authorised by the account holder using Secure Customer Authentication (MFA) - i.e. if an attacker has knowledge of an account number, it does not enable them to make a fraudulent payment transaction. PSD2 makes this clear in Article 4(32):
“For the activities of payment initiation service providers and account information service providers, the name of the account owner and the account number do not constitute sensitive payment data;”
4. PISPs and ASPSPs are not Service Providers to each other
I’ve heard of assessors to ASPSPs demanding that every PISP who sends the ASPSP payment instructions including PAN as a reference must comply with PCI DSS, this is wrong. A PISP is not a Service Provider to the ASPSP in PCI DSS terms.
I’ve also heard of assessors to PISPs demanding that every ASPSP to whom the PISP sends payment instructions including PAN as a reference must comply with PCI DSS, this is also wrong. An ASPSP is not a Service Provider to the PISP in PCI DSS terms.
Perhaps this can be confusing for PCI DSS assessors because the words in the PCI DSS Attestation of Compliance (AoC) say:
“For the services being validated, does the entity have relationships with one or more third-party service provider that store, process, or transmit account data on the entity’s behalf (for example, payment gateways, payment processors, payment service providers (PSPs, and off-site storage)).”
The key point is that a PISP isn’t acting on an ASPSP’s behalf, and an ASPSP is not acting on a PISP’s behalf. They are both conducting independent operations allowed for under PSD2/PSR. Additionally the use of the term PSP in the AoC isn’t helpful when PSD2 uses PSP in a totally different context.
Many assessors and people in the PCI world have this strange belief that anyone who stores, processes or transmits cardholder data has to comply with PCI DSS, as if PCI DSS compliance is a universal law (it isn’t).7
Of course some PISPs and ASPSPs may well be existing participants in the card payment ecosystem, for example they may be an acquirer, an issuer or a payment-ecosystem-PSP. Therefore they may already have card brand imposed contracts in place that require them to comply with PCI DSS. However, this doesn’t mean that a PISP can ask an ASPSP for its Attestation of Compliance, and similarly an ASPSP cannot request an AoC from a PISP.
My intention in this post is to clarify the contractual position regarding compliance with PCI DSS and what PSD2 / PSR says. Of course, PISPs and ASPSPs need to take the appropriate security steps, and if I was in charge of security at such an entity, I’d have a control framework that would comply with the EBA guidelines and might be based on NIST CSF or ISO27001, but which would probably also incorporate many of the control requirements in PCI DSS.
If you found this analysis useful or informative, subscribing will encourage me to write more. You’ll also receive each new article in your inbox.
If you know someone else who would find this article useful, please share it with them.
A PISP as defined in PSD2 is not the same as a PSP as we understand them in the card payments ecosystem. If you’re from card payments you can think of them as a combination of a PSP and an acquirer, but unlike a payment-ecosystem-PSP they are regulated by a national financial regulator, like the FCA.
An ASPSP is effectively an entity that provides something like a bank account or a credit card account. The Open Banking Implementation Entity’s glossary is helpful https://www.openbanking.org.uk/glossary/, as is this explanation of the OB ecosystem from TrueLayer https://truelayer.com/blog/product/what-is-an-aspsp/.
For the purposes of this discussion, this doesn’t include the situation where an entity is required to comply with PCI DSS because of a national or state, law or regulation.
European Union Payment Services Directive No. 2
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02015L2366-20240408
The Payment Services Regulations which in the UK implement PDS2 in UK law.
https://www.legislation.gov.uk/uksi/2017/752/contents
Although see note 3, in some countries and states, compliance with PCI DSS is a local law that’s applicable depending on the role an entity plays in the card payment ecosystem.