Let's continue our series of blogs on the Payment Card Industry’s Data Security Standard (PCI DSS) and its application to different industries. In this blog, we’re going to discuss the PCI DSS relationship with issuers and acquirers. We published the first three parts concerning ATM environments, the retail industry and the hospitality industry in earlier blogs. 

So, how does PCI DSS affect issuers and acquirers? Let's analyze them separately.

Issuers

In the very early days of PCI DSS, there was a common myth that PCI DSS did not apply to issuers, mainly because of the infamous requirement 3.2 'Do not store sensitive authentication data (after authorization)'. This gave the grounds for interpretation that since issuers must store some sensitive authentication data surely the standard does not apply to them. However, most payment card scheme FAQs did state that PCI DSS applies to any entities storing, processing or transmitting cardholder data, including issuers. The interpretation issue was resolved when a note was added to PCI DSS v2 requirement 3.2 explaining that issuers can store sensitive authentication data securely if there's a valid business justification. PCI DSS v4.0 should clarify this in even more detail. You can get some insight into the protection of sensitive authentication data in our blog dedicated to Hospitality Industry.

To be more specific let's look at each type of sensitive authentication data that an issuer may have a valid business justification for storing and therefore needs adequate protection.

PIN data (PIN block or encrypted PIN) must be stored by issuers, and the security controls concerning this are covered by separate specific and stringent PCI PIN security requirements . Where these PIN security requirements apply, Qualified Security Assessors (QSAs) will be less concerned during a PCI DSS assessment knowing that PIN Security requirements are much more stringent than those of PCI DSS.

The card verification code or value can be a hot topic as you might think that there's no need to store it since issuers can 're-calculate' this value every time it's needed to verify a card-not-present transaction. Nevertheless, in reality, sometimes it is stored, and sometimes it is not stored by issuers. After all, it's up to the issuers to identify a business justification allowing them to store sensitive authentication data, and a QSA would not be able to challenge a robust business justification. The full contents of any track or equivalent data contained on a chip generally have to be stored by issuers and as such needs to be protected, however, currently the level to which protection must be applied is not always clear . Hopefully, PCI DSS v4.0 will address this requirement in further detail.

As for the rest of the standard, PCI DSS applies to issuers in the same way as any other organization. Perhaps one specific in maintaining PCI DSS compliance is bearing in mind potential (if not outsourced) contact with cardholders and avoiding bad practices that could lead to increased scope, for example, using PAN as one of the identification methods of cardholders.

When it comes to PCI DSS compliance validation, as you might expect, there's usually less pressure on issuers from payment card schemes. And there's a good reason why - even if a company, which is only an issuer in the PCI DSS world, is compromised, any cardholder data related fraud impact will be limited to the cardholder data held by the issuer and associated costs will be covered by that issuer.

Acquirers

What is most important for payment card schemes is to manage merchant compliance, which they can only do with the help of acquirers. Because usually there's no direct relationship between merchants and payment card schemes, acquirers play the most important role in making sure merchants are PCI DSS compliant.

Acquirers are usually given certain thresholds for merchant compliance by payment card schemes, for example, 100% of Level 1 merchants, 90% of Level 2 merchants and 80% of Level 3 merchants should be PCI DSS compliant. Since acquirers can determine merchant levels themselves (based on guidelines, but not hard rules), this gives some flexibility for acquirers 'to play' with their merchant population.

On the other hand, merchants can also use some tricks, for example, using different acquirers for multiple, or even the same, payment channels, splitting their transaction volume and subsequently reducing their merchant level. Of course, merchants don't have to divulge data about transaction volume with other acquirers as this is commercially sensitive information. In fact, there used to be a Yes/No question 'If merchant accepts any transactions with another acquirer(s)' within the merchant's Attestation of Compliance, but even this was removed at some point, as, most probably, there was no easy way to verify the information and it was also on the border of being commercially sensitive. In any case, when it comes to PCI DSS compliance, the biggest challenge for acquirers is to manage their merchant population, especially if we're talking about five-figure numbers, which is not uncommon. This is where technology such as ZeroRisk Suite can help to manage a merchant portfolio.

In summary, it may seem that both issuers and acquirers are subject to less stringent PCI DSS validation requirements imposed by payment card schemes, but they both have their own specific issues and considerations when it comes to PCI DSS compliance.

To ensure that you’re keeping cardholder data protected, get in touch with our cyber security experts. The PCI compliance journey may seem overwhelming, but we are more than ready to walk you through this journey guaranteeing that nothing is missed.

Contact us

Column Header Text Column Header Text Column Header Text

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Discover More

Advantio_Blog_DNS_Diagram_V1 Image caption goes here. This is HTML text.

Information security professional with 12+ years of experience in information security consulting, 2+ years of experience in the role of information security manager, and 2+ years of experience in large scale governmental IT project management. Developed and delivered PCI DSS Implementation and ATM Security training sessions in 15+ different countries. Certified as Qualified Security Assessor (QSA) by PCI Security Standards Council, holding CISM, CISA and CISSP certifications in good standing.

Comments